Improve concepts organization (#5095)

* cleanup unused files

* tweak wording

* merge traffic management architecture material

* reorg top level concept sections

* lint errors

* fix list style

content/en/blog/2018/egress-https/index.md

@@ -189,7 +189,7 @@ in this case `www.googleapis.com`.
 To allow Istio to perform monitoring and policy enforcement of egress requests based on HTTP details, the microservices
 must issue HTTP requests. Istio then opens an HTTPS connection to the destination (performs TLS origination). The code
 of the microservices must be written differently or configured differently, according to whether the microservice runs
-inside or outside an Istio service mesh. This contradicts the Istio design goal of [maximizing transparency](/docs/concepts/what-is-istio/#design-goals). Sometimes you need to compromise...
+inside or outside an Istio service mesh. This contradicts the Istio design goal of [maximizing transparency](/docs/concepts/architecture/#design-goals). Sometimes you need to compromise...
 
 The diagram below shows two options for sending HTTPS traffic to external services. On the top, a microservice sends
 regular HTTPS requests, encrypted end-to-end. On the bottom, the same microservice sends unencrypted HTTP requests

content/en/blog/2019/app-identity-and-access-adapter/index.md

@@ -15,9 +15,9 @@ With the [App Identity and Access Adapter](https://github.com/ibm-cloud-security
 
 ## Understanding Istio and the adapter
 
-[Istio](/docs/concepts/what-is-istio/) is an open source service mesh that transparently layers onto distributed applications and seamlessly integrates with Kubernetes. To reduce the complexity of deployments Istio provides behavioral insights and operational control over the service mesh as a whole. [See Istio Architecture for more details.](/docs/concepts/what-is-istio/#architecture)
+[Istio](/docs/concepts/what-is-istio/) is an open source service mesh that transparently layers onto distributed applications and seamlessly integrates with Kubernetes. To reduce the complexity of deployments Istio provides behavioral insights and operational control over the service mesh as a whole. [See Istio Architecture for more details.](/docs/concepts/architecture/)
 
-Istio uses [Envoy proxy sidecars](/blog/2019/data-plane-setup/) to mediate inbound and outbound traffic for all pods in the service mesh. Istio extracts telemetry from the Envoy sidecars and sends it to [Mixer](/docs/concepts/what-is-istio/#mixer), the Istio component responsible for collecting telemetry and policy enforcement.
+Istio uses [Envoy proxy sidecars](/blog/2019/data-plane-setup/) to mediate inbound and outbound traffic for all pods in the service mesh. Istio extracts telemetry from the Envoy sidecars and sends it to [Mixer](/docs/concepts/architecture/#mixer), the Istio component responsible for collecting telemetry and policy enforcement.
 
 The App Identity and Access adapter extends the Mixer functionality by analyzing the telemetry (attributes) against various access control policies across the service mesh. The access control policies can be linked to a particular Kubernetes services and can be finely tuned to specific service endpoints. For more information about policies and telemetry, see the Istio documentation.
 

content/en/blog/2019/data-plane-setup/index.md

@@ -10,7 +10,7 @@ keywords: [kubernetes,sidecar-injection, traffic-management]
 ---
 A simple overview of an Istio service-mesh architecture always starts with describing the control-plane and data-plane.
 
-[From Istio’s documentation:](/docs/concepts/what-is-istio/#architecture)
+[From Istio’s documentation:](/docs/concepts/architecture/)
 
 {{< quote >}}
 An Istio service mesh is logically split into a data plane and a control plane.

content/en/blog/2019/performance-best-practices/index.md

@@ -12,7 +12,7 @@ Service meshes add a lot of functionality to application deployments, including
 
 Earlier this year, we published a [blog post](/blog/2019/istio1.1_perf/) on Istio's performance improvements in version 1.1. Following the release of [Istio 1.2](/news/2019/announcing-1.2), we want to provide guidance and tools to help you benchmark Istio's data plane performance in a production-ready Kubernetes environment.
 
-Overall, we found that Istio's [sidecar proxy](/docs/concepts/what-is-istio/#envoy) latency scales with the number of concurrent connections. At 1000 requests per second (RPS), across 16 connections, Istio adds **3 milliseconds** per request in the 50th percentile, and **10 milliseconds** in the 99th percentile.
+Overall, we found that Istio's [sidecar proxy](/docs/concepts/architecture/#envoy) latency scales with the number of concurrent connections. At 1000 requests per second (RPS), across 16 connections, Istio adds **3 milliseconds** per request in the 50th percentile, and **10 milliseconds** in the 99th percentile.
 
 In the [Istio Tools repository](https://github.com/istio/tools/tree/3ac7ab40db8a0d595b71f47b8ba246763ecd6213/perf/benchmark), you’ll find scripts and instructions for measuring Istio's data plane performance, with additional instructions on how to run the scripts with [Linkerd](https://linkerd.io), another service mesh implementation. [Follow along](https://github.com/istio/tools/tree/3ac7ab40db8a0d595b71f47b8ba246763ecd6213/perf/benchmark#setup) as we detail some best practices for each step of the performance test framework.
 

content/en/docs/concepts/architecture/index.md

@@ -0,0 +1,195 @@
+---
+title: Architecture
+description: Describes Istio's high-level architecture and design goals.
+weight: 70
+---
+
+An Istio service mesh is logically split into a **data plane** and a **control
+plane**.
+
+* The **data plane** is composed of a set of intelligent proxies
+  ([Envoy](https://www.envoyproxy.io/)) deployed as sidecars. These proxies
+  mediate and control all network communication between microservices along
+  with [Mixer](/docs/reference/config/policy-and-telemetry/), a general-purpose
+  policy and telemetry hub.
+
+* The **control plane** manages and configures the proxies to route traffic.
+  Additionally, the control plane configures Mixers to enforce policies and
+  collect telemetry.
+
+The following diagram shows the different components that make up each plane:
+
+{{< image width="80%"
+    link="./arch.svg"
+    alt="The overall architecture of an Istio-based application."
+    caption="Istio Architecture"
+    >}}
+
+Traffic in Istio is categorized as data plane traffic and control plane traffic.
+Data plane traffic refers to the messages that the business logic of the workloads
+send and receive. Control plane traffic refers to configuration and control messages sent
+between Istio components to program the behavior of the mesh. Traffic management
+in Istio refers exclusively to data plane traffic.
+
+## Components
+
+The following sections provide a brief overview of each of Istio's core components.
+
+### Envoy
+
+Istio uses an extended version of the
+[Envoy](https://envoyproxy.github.io/envoy/) proxy. Envoy is a high-performance
+proxy developed in C++ to mediate all inbound and outbound traffic for all
+services in the service mesh.
+Envoy proxies are the only Istio components that interact with data plane
+traffic.
+
+Envoy proxies are deployed as sidecars to services, logically
+augmenting the services with Envoy’s many built-in features,
+for example:
+
+* Dynamic service discovery
+* Load balancing
+* TLS termination
+* HTTP/2 and gRPC proxies
+* Circuit breakers
+* Health checks
+* Staged rollouts with %-based traffic split
+* Fault injection
+* Rich metrics
+
+This sidecar deployment allows Istio to extract a wealth of signals about traffic behavior as
+[attributes](/docs/reference/config/policy-and-telemetry/mixer-overview/#attributes).
+Istio can, in turn, use these attributes in [Mixer](/docs/reference/config/policy-and-telemetry/)
+to enforce policy decisions, and send them to monitoring systems to provide
+information about the behavior of the entire mesh.
+
+The sidecar proxy model also allows you to add Istio capabilities to an
+existing deployment with no need to rearchitect or rewrite code. You can read
+more about why we chose this approach in our
+[Design Goals](#design-goals).
+
+Some of the Istio features and tasks enabled by Envoy proxies include:
+
+* Traffic control features: enforce fine-grained traffic control with rich
+  routing rules for HTTP, gRPC, WebSocket, and TCP traffic.
+
+* Network resiliency features: setup retries, failovers, circuit breakers, and
+  fault injection.
+
+* Security and authentication features: enforce security policies and enforce
+  access control and rate limiting defined through the configuration API.
+
+### Mixer
+
+[Mixer](/docs/reference/config/policy-and-telemetry/) is a platform-independent
+component. Mixer enforces access control and usage policies across the service
+mesh, and collects telemetry data from the Envoy proxy and other services. The
+proxy extracts request level
+[attributes](/docs/reference/config/policy-and-telemetry/mixer-overview/#attributes), and sends them
+to Mixer for evaluation. You can find more information on this attribute
+extraction and policy evaluation in our [Mixer Configuration
+documentation](/docs/reference/config/policy-and-telemetry/mixer-overview/#configuration-model).
+
+Mixer includes a flexible plugin model. This model enables Istio to interface
+with a variety of host environments and infrastructure backends. Thus, Istio
+abstracts the Envoy proxy and Istio-managed services from these details.
+
+### Pilot
+
+Pilot provides
+service discovery for the Envoy sidecars, traffic management capabilities
+for intelligent routing (e.g., A/B tests, canary rollouts, etc.),
+and resiliency (timeouts, retries, circuit breakers, etc.).
+
+Pilot converts high level routing rules that control traffic behavior into
+Envoy-specific configurations, and propagates them to the sidecars at runtime.
+Pilot abstracts platform-specific service discovery mechanisms and synthesizes
+them into a standard format that any sidecar conforming with the
+[Envoy API](https://www.envoyproxy.io/docs/envoy/latest/api/api) can consume.
+
+The following diagram shows how the platform adapters and Envoy proxies
+interact.
+
+{{< image width="40%" link="./discovery.svg" caption="Service discovery" >}}
+
+1.  The platform starts a new instance of a service which notifies its platform
+    adapter.
+
+1.  The platform adapter registers the instance with the Pilot abstract model.
+
+1.  **Pilot** distributes traffic rules and configurations to the Envoy proxies
+    to account for the change.
+
+This loose coupling allows Istio to run on multiple environments such as Kubernetes,
+Consul, or Nomad, while maintaining the same operator interface for traffic
+management.
+
+You can use Istio's
+[Traffic Management API](/docs/concepts/traffic-management/#introducing-istio-traffic-management)
+to instruct Pilot to refine the Envoy configuration to exercise more granular control
+over the traffic in your service mesh.
+
+### Citadel
+
+[Citadel](/docs/concepts/security/) enables strong service-to-service and
+end-user authentication with built-in identity and credential management. You
+can use Citadel to upgrade unencrypted traffic in the service mesh. Using
+Citadel, operators can enforce policies based on service identity rather than
+on relatively unstable layer 3 or layer 4 network identifiers. Starting from
+release 0.5, you can use [Istio's authorization feature](/docs/concepts/security/#authorization)
+to control who can access your services.
+
+### Galley
+
+Galley is Istio's configuration validation, ingestion, processing and
+distribution component. It is responsible for insulating
+the rest of the Istio components from the details of obtaining user
+configuration from the underlying platform (e.g. Kubernetes).
+
+## Design goals
+
+A few key design goals informed Istio’s architecture. These goals are essential
+to making the system capable of dealing with services at scale and with high
+performance.
+
+* **Maximize Transparency**: To adopt Istio, an operator or developer is
+  required to do the minimum amount of work possible to get real value from the
+  system. To this end, Istio can automatically inject itself into all the
+  network paths between services. Istio uses sidecar proxies to capture traffic
+  and, where possible, automatically program the networking layer to route
+  traffic through those proxies without any changes to the deployed application
+  code. In Kubernetes, the proxies are injected into {{<gloss pod>}}pods{{</gloss>}} and traffic is
+  captured by programming ``iptables`` rules. Once the sidecar proxies are
+  injected and traffic routing is programmed, Istio can mediate all traffic.
+  This principle also applies to performance. When applying Istio to a
+  deployment, operators see a minimal increase in resource costs for the
+  functionality being provided. Components and APIs must all be designed with
+  performance and scale in mind.
+
+* **Extensibility**: As operators and developers become more dependent on the
+  functionality that Istio provides, the system must grow with their needs.
+  While we continue to add new features, the greatest need is the ability to
+  extend the policy system, to integrate with other sources of policy and
+  control, and to propagate signals about mesh behavior to other systems for
+  analysis. The policy runtime supports a standard extension mechanism for
+  plugging in other services. In addition, it allows for the extension of its
+  vocabulary to allow policies to be enforced based on new signals that the
+  mesh produces.
+
+* **Portability**: The ecosystem in which Istio is used varies along many
+  dimensions. Istio must run on any cloud or on-premises environment with
+  minimal effort. The task of porting Istio-based services to new environments
+  must be trivial. Using Istio, you are able to operate a single service
+  deployed into multiple environments. For example, you can deploy on multiple
+  clouds for redundancy.
+
+* **Policy Uniformity**: The application of policy to API calls between
+  services provides a great deal of control over mesh behavior. However, it can
+  be equally important to apply policies to resources which are not necessarily
+  expressed at the API level. For example, applying a quota to the amount of
+  CPU consumed by an ML training task is more useful than applying a quota to
+  the call which initiated the work. To this end, Istio maintains the policy
+  system as a distinct service with its own API rather than the policy system
+  being baked into the proxy sidecar, allowing services to directly integrate
+  with it as needed.

content/en/docs/concepts/observability/index.md

@@ -19,7 +19,7 @@ Istio, operators gain a thorough understanding of how monitored services are int
 Istio generates the following types of telemetry in order to provide overall service mesh observability:
 
 - [**Metrics**](#metrics). Istio generates a set of service metrics based on the four "golden signals" of monitoring (latency, traffic, errors, and
-  saturation). Istio also provides detailed metrics for the [mesh control plane](/docs/concepts/what-is-istio/#architecture).
+  saturation). Istio also provides detailed metrics for the [mesh control plane](/docs/concepts/architecture/).
   A default set of mesh monitoring dashboards built on top of these metrics is also provided.
 - [**Distributed Traces**](#distributed-traces). Istio generates distributed trace spans for each service, providing operators with a detailed understanding
   of call flows and service dependencies within a mesh.

content/en/docs/concepts/policies/index.md

@@ -0,0 +1,16 @@
+---
+title: Policies
+description: Describes Istio's policy management functionality.
+weight: 30
+keywords: [policy,policies]
+---
+
+Istio lets you configure custom policies for your application to enforce rules at runtime such as:
+
+- Rate limiting to dynamically limit the traffic to a service
+- Denials, whitelists, and blacklists, to restrict access to services
+- Header rewrites and redirects
+
+Istio also lets you create your own [policy adapters](/docs/tasks/policy-enforcement/control-headers) to add, for example, your own custom authorization behavior.
+
+You must enable policy enforcement for your mesh to use this feature.

content/en/docs/concepts/security/index.md

@@ -1,7 +1,7 @@
 ---
-title: Policies and Security
+title: Security
 description: Describes Istio's authorization and authentication functionality.
-weight: 30
+weight: 25
 keywords: [security,policy,policies,authentication,authorization,rbac,access-control]
 aliases:
     - /docs/concepts/network-and-auth/auth.html
@@ -40,18 +40,6 @@ and audit (AAA) tools to protect your services and data. The goals of Istio secu
 Visit our [Mutual TLS Migration docs](/docs/tasks/security/mtls-migration/) to start using Istio security features with your deployed services.
 Visit our [Security Tasks](/docs/tasks/security/) for detailed instructions to use the security features.
 
-## Policies
-
-Istio lets you configure custom policies for your application to enforce rules at runtime such as:
-
-- Rate limiting to dynamically limit the traffic to a service
-- Denials, whitelists, and blacklists, to restrict access to services
-- Header rewrites and redirects
-
-Istio also lets you create your own [policy adapters](/docs/tasks/policy-enforcement/control-headers) to add, for example, your own custom authorization behavior.
-
-You must enable policy enforcement for your mesh to use this feature.
-
 ## High-level architecture
 
 Security in Istio involves multiple components:

content/en/docs/concepts/traffic-management/index.md

@@ -28,8 +28,8 @@ it easy to direct and control traffic around your mesh without making any
 changes to your services.
 
 If you’re interested in the details of how the features described in this guide
-work, you can find out more about Istio’s traffic management architecture in the
-[Architecture](#architecture) section at the end of this document. The rest of
+work, you can find out more about Istio’s traffic management implementation in the
+[architecture overview](/docs/concepts/architecture/). The rest of
 this guide introduces Istio’s traffic management features.
 
 ## Introducing Istio Traffic Management
@@ -812,98 +812,3 @@ or errors and take appropriate fallback actions. For example, when all
 instances in a load balancing pool have failed, Envoy returns an `HTTP 503`
 code. The application must implement any fallback logic needed to handle the
 `HTTP 503` error code..
-
-## Architecture {#architecture}
-
-Istio's traffic management model relies on the following two components:
-
--   {{< gloss >}}Pilot{{</ gloss >}}, the core traffic management component.
--   {{< gloss >}}Envoy{{</ gloss >}} proxies, which enforce configurations and
-    policies set through Pilot.
-
-These components enable the following Istio traffic management features:
-
--   Service discovery
--   Load balancing
--   Traffic routing and control
-
-### Pilot: Core traffic management {#pilot}
-
-The following diagram shows the Pilot architecture:
-
-{{< image width="40%" link="./pilot-arch.svg" caption="Pilot architecture" >}}
-
-As the diagram illustrates, Pilot maintains an **abstract model** of all the
-services in the mesh. **Platform-specific adapters** in Pilot translate the
-abstract model appropriately for your platform. For example, the Kubernetes
-adapter implements controllers to watch the Kubernetes API server for changes to
-pod registration information and service resources. The Kubernetes adapter
-translates this data for the abstract model.
-
-Pilot uses the abstract model to generate appropriate Envoy-specific
-configurations to let Envoy proxies know about one another in the mesh through
-the [Envoy API](https://www.envoyproxy.io/docs/envoy/latest/api/api).
-
-You can use Istio's [Traffic Management API](#introducing-istio-traffic-management) to instruct Pilot to refine the
-Envoy configuration to exercise more granular control over the traffic in your
-service mesh.
-
-### Envoy proxies
-
-Traffic in Istio is categorized as data plane traffic and control plane traffic.
-Data plane traffic refers to the messages that the business logic of the workloads
-send and receive. Control plane traffic refers to configuration and control messages sent
-between Istio components to program the behavior of the mesh. Traffic management
-in Istio refers exclusively to data plane traffic.
-
-Envoy proxies are the only Istio components that interact with data plane
-traffic. Envoy proxies route the data plane traffic across the mesh and enforce
-the configurations and traffic rules without the services having to be aware of
-them. Envoy proxies mediate all inbound and outbound traffic for all services in
-the mesh. Envoy proxies are deployed as sidecars to services, logically
-augmenting the services with traffic management features:
-
--   service discovery and load balancing
--   traffic routing and configuration
--   network resilience and testing
-
-Some of the features and tasks enabled by Envoy proxies include:
-
--   Traffic control features: enforce fine-grained traffic control with rich
-    routing rules for HTTP, gRPC, WebSocket, and TCP traffic.
-
--   Network resiliency features: setup retries, failovers, circuit breakers, and
-    fault injection.
-
--   Security and authentication features: enforce security policies and enforce
-    access control and rate limiting defined through the configuration API.
-
-#### Service discovery and load balancing {#discovery}
-
-Istio service discovery leverages the service discovery features provided by
-platforms like Kubernetes for container-based applications. Service discovery
-works in a similar way regardless of what platform you're using:
-
-1.  The platform starts a new instance of a service which notifies its platform
-    adapter.
-
-1.  The platform adapter registers the instance with the Pilot abstract model.
-
-1.  **Pilot** distributes traffic rules and configurations to the Envoy proxies
-    to account for the change.
-
-The following diagram shows how the platform adapters and Envoy proxies
-interact.
-
-{{< image width="40%" link="./discovery.svg" caption="Service discovery" >}}
-
-Because the service discovery feature is platform-independent, a service mesh
-can include services across multiple platforms.
-
-Using the abstract model, Pilot configures the Envoy proxies to perform load
-balancing for service requests, replacing any underlying platform-specific load
-balancing feature. In the absence of more specific routing rules, Envoy will
-distribute the traffic across the instances in the calling service's load
-balancing pool, according to the Pilot abstract model and load balancer
-configuration.
-

content/en/docs/concepts/what-is-istio/index.md

@@ -61,6 +61,8 @@ staged rollouts with percentage-based traffic splits.
 With better visibility into your traffic, and out-of-box failure recovery features, you can catch issues before they cause problems, making calls more reliable,
 and your network more robust -- no matter what conditions you face.
 
+Refer to the [Traffic management concepts guide](/docs/concepts/traffic-management/) for more details.
+
 ### Security
 
 Istio’s security capabilities free developers to focus on security at the application level. Istio provides the underlying secure communication channel, and
@@ -70,6 +72,20 @@ letting you enforce policies consistently across diverse protocols and runtimes
 While Istio is platform independent, using it with Kubernetes (or infrastructure) network policies, the benefits are even greater, including the ability to
 secure {{<gloss>}}pod{{</gloss>}}-to-pod or service-to-service communication at the network and application layers.
 
+Refer to the [Security concepts guide](/docs/concepts/security/) for more details.
+
+### Policies
+
+Istio lets you configure custom policies for your application to enforce rules at runtime such as:
+
+* Rate limiting to dynamically limit the traffic to a service
+* Denials, whitelists, and blacklists, to restrict access to services
+* Header rewrites and redirects
+
+Istio also lets you create your own [policy adapters](/docs/tasks/policy-enforcement/control-headers) to add, for example, your own custom authorization behavior.
+
+Refer to the [Policies concepts guide](/docs/concepts/policies/) for more details.
+
 ### Observability
 
 Istio’s robust tracing, monitoring, and logging features give you deep insights into your service mesh deployment. Gain a real understanding of how service performance
@@ -83,7 +99,9 @@ and infrastructure backends.
 All these features let you more effectively set, monitor, and enforce SLOs on services. Of course, the bottom line is that you can detect and fix issues quickly
 and efficiently.
 
-### Platform support
+Refer to the [Observability concepts guide](/docs/concepts/observability/) for more details.
+
+## Platform support
 
 Istio is platform-independent and designed to run in a variety of environments, including those spanning Cloud, on-premise, Kubernetes, Mesos, and more. You can
  deploy Istio on Kubernetes, or on Nomad with Consul. Istio currently supports:
@@ -94,156 +112,7 @@ Istio is platform-independent and designed to run in a variety of environments,
 
 * Services running on individual virtual machines
 
-### Integration and customization
+## Integration and customization
 
 The policy enforcement component of Istio can be extended and customized to integrate with existing solutions for ACLs, logging, monitoring, quotas, auditing,
 and more.
-
-## Architecture
-
-An Istio service mesh is logically split into a **data plane** and a **control
-plane**.
-
-* The **data plane** is composed of a set of intelligent proxies
-  ([Envoy](https://www.envoyproxy.io/)) deployed as sidecars. These proxies
-  mediate and control all network communication between microservices along
-  with [Mixer](/docs/reference/config/policy-and-telemetry/), a general-purpose
-  policy and telemetry hub.
-
-* The **control plane** manages and configures the proxies to route traffic.
-  Additionally, the control plane configures Mixers to enforce policies and
-  collect telemetry.
-
-The following diagram shows the different components that make up each plane:
-
-{{< image width="80%"
-    link="./arch.svg"
-    alt="The overall architecture of an Istio-based application."
-    caption="Istio Architecture"
-    >}}
-
-### Envoy
-
-Istio uses an extended version of the
-[Envoy](https://envoyproxy.github.io/envoy/) proxy. Envoy is 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,
-for example:
-
-* Dynamic service discovery
-* Load balancing
-* TLS termination
-* HTTP/2 and gRPC proxies
-* Circuit breakers
-* Health checks
-* Staged rollouts with %-based traffic split
-* Fault injection
-* Rich metrics
-
-Envoy is deployed as a **sidecar** to the relevant service in the same
-Kubernetes {{<gloss>}}pod{{</gloss>}}. This deployment allows Istio to extract a wealth of signals
-about traffic behavior as
-[attributes](/docs/reference/config/policy-and-telemetry/mixer-overview/#attributes). Istio can, in
-turn, use these attributes in [Mixer](/docs/reference/config/policy-and-telemetry/)
-to enforce policy decisions, and send them to monitoring systems to provide
-information about the behavior of the entire mesh.
-
-The sidecar proxy model also allows you to add Istio capabilities to an
-existing deployment with no need to rearchitect or rewrite code. You can read
-more about why we chose this approach in our [Design
-Goals](/docs/concepts/what-is-istio/#design-goals).
-
-### Mixer
-
-[Mixer](/docs/reference/config/policy-and-telemetry/) is a platform-independent
-component. Mixer enforces access control and usage policies across the service
-mesh, and collects telemetry data from the Envoy proxy and other services. The
-proxy extracts request level
-[attributes](/docs/reference/config/policy-and-telemetry/mixer-overview/#attributes), and sends them
-to Mixer for evaluation. You can find more information on this attribute
-extraction and policy evaluation in our [Mixer Configuration
-documentation](/docs/reference/config/policy-and-telemetry/mixer-overview/#configuration-model).
-
-Mixer includes a flexible plugin model. This model enables Istio to interface
-with a variety of host environments and infrastructure backends. Thus, Istio
-abstracts the Envoy proxy and Istio-managed services from these details.
-
-### Pilot
-
-[Pilot](/docs/concepts/traffic-management/#pilot) provides
-service discovery for the Envoy sidecars, traffic management capabilities
-for intelligent routing (e.g., A/B tests, canary rollouts, etc.),
-and resiliency (timeouts, retries, circuit breakers, etc.).
-
-Pilot converts high level routing rules that control traffic behavior into
-Envoy-specific configurations, and propagates them to the sidecars at runtime.
-Pilot abstracts platform-specific service discovery mechanisms and synthesizes
-them into a standard format that any sidecar conforming with the [Envoy data
-plane APIs](https://github.com/envoyproxy/data-plane-api) can consume. This
-loose coupling allows Istio to run on multiple environments such as Kubernetes,
-Consul, or Nomad, while maintaining the same operator interface for traffic
-management.
-
-### Citadel
-
-[Citadel](/docs/concepts/security/) enables strong service-to-service and
-end-user authentication with built-in identity and credential management. You
-can use Citadel to upgrade unencrypted traffic in the service mesh. Using
-Citadel, operators can enforce policies based on service identity rather than
-on relatively unstable layer 3 or layer 4 network identifiers. Starting from
-release 0.5, you can use [Istio's authorization feature](/docs/concepts/security/#authorization)
-to control who can access your services.
-
-### Galley
-
-Galley is Istio's configuration validation, ingestion, processing and
-distribution component. It is responsible for insulating
-the rest of the Istio components from the details of obtaining user
-configuration from the underlying platform (e.g. Kubernetes).
-
-## Design Goals
-
-A few key design goals informed Istio’s architecture. These goals are essential
-to making the system capable of dealing with services at scale and with high
-performance.
-
-* **Maximize Transparency**: To adopt Istio, an operator or developer is
-  required to do the minimum amount of work possible to get real value from the
-  system. To this end, Istio can automatically inject itself into all the
-  network paths between services. Istio uses sidecar proxies to capture traffic
-  and, where possible, automatically program the networking layer to route
-  traffic through those proxies without any changes to the deployed application
-  code. In Kubernetes, the proxies are injected into {{<gloss pod>}}pods{{</gloss>}} and traffic is
-  captured by programming ``iptables`` rules. Once the sidecar proxies are
-  injected and traffic routing is programmed, Istio can mediate all traffic.
-  This principle also applies to performance. When applying Istio to a
-  deployment, operators see a minimal increase in resource costs for the
-  functionality being provided. Components and APIs must all be designed with
-  performance and scale in mind.
-
-* **Extensibility**: As operators and developers become more dependent on the
-  functionality that Istio provides, the system must grow with their needs.
-  While we continue to add new features, the greatest need is the ability to
-  extend the policy system, to integrate with other sources of policy and
-  control, and to propagate signals about mesh behavior to other systems for
-  analysis. The policy runtime supports a standard extension mechanism for
-  plugging in other services. In addition, it allows for the extension of its
-  vocabulary to allow policies to be enforced based on new signals that the
-  mesh produces.
-
-* **Portability**: The ecosystem in which Istio is used varies along many
-  dimensions. Istio must run on any cloud or on-premises environment with
-  minimal effort. The task of porting Istio-based services to new environments
-  must be trivial. Using Istio, you are able to operate a single service
-  deployed into multiple environments. For example, you can deploy on multiple
-  clouds for redundancy.
-
-* **Policy Uniformity**: The application of policy to API calls between
-  services provides a great deal of control over mesh behavior. However, it can
-  be equally important to apply policies to resources which are not necessarily
-  expressed at the API level. For example, applying a quota to the amount of
-  CPU consumed by an ML training task is more useful than applying a quota to
-  the call which initiated the work. To this end, Istio maintains the policy
-  system as a distinct service with its own API rather than the policy system
-  being baked into the proxy sidecar, allowing services to directly integrate
-  with it as needed.

content/en/docs/examples/mesh-expansion/multi-network/index.md

@@ -74,7 +74,7 @@ cluster for mesh expansion, run the following commands on a machine with cluster
           -o jsonpath='{.data.cert-chain\.pem}' | base64 --decode > cert-chain.pem
     {{< /text >}}
 
-1. Determine and store the IP address of the Istio ingress gateway since the mesh expansion machines access [Citadel](/docs/concepts/security/) and [Pilot](/docs/concepts/traffic-management/#pilot) and workloads on cluster through this IP address.
+1. Determine and store the IP address of the Istio ingress gateway since the mesh expansion machines access [Citadel](/docs/concepts/security/) and [Pilot](/docs/concepts/architecture/#pilot) and workloads on cluster through this IP address.
 
     {{< text bash >}}
     $ export GWIP=$(kubectl get -n istio-system service istio-ingressgateway -o jsonpath='{.status.loadBalancer.ingress[0].ip}')

content/en/docs/examples/mesh-expansion/single-network/index.md

@@ -78,7 +78,7 @@ cluster for mesh expansion, run the following commands on a machine with cluster
     $ export SERVICE_NAMESPACE="default"
     {{< /text >}}
 
-1. Determine and store the IP address of the Istio ingress gateway since the mesh expansion machines access [Citadel](/docs/concepts/security/) and [Pilot](/docs/concepts/traffic-management/#pilot) through this IP address.
+1. Determine and store the IP address of the Istio ingress gateway since the mesh expansion machines access [Citadel](/docs/concepts/security/) and [Pilot](/docs/concepts/architecture/#pilot) through this IP address.
 
     {{< text bash >}}
     $ export GWIP=$(kubectl get -n istio-system service istio-ingressgateway -o jsonpath='{.status.loadBalancer.ingress[0].ip}')

content/en/docs/ops/traffic-management/introduction/index.md

@@ -19,7 +19,7 @@ other content.
 When attempting to understand, monitor or troubleshoot the networking within
 an Istio deployment it is critical to understand the fundamental Istio
 concepts starting with the service mesh.  The service mesh is described
-in [Architecture](/docs/concepts/what-is-istio/#architecture).  As noted
+in [Architecture](/docs/concepts/architecture/).  As noted
 in the architecture section Istio has a distinct control plane and a data
 plane and operationally it will be important to be able to monitor the
 network state of both.  The service mesh is a fully interconnected set of

content/en/docs/tasks/traffic-management/egress/egress_sni_monitoring_and_policies/index.md

@@ -92,7 +92,7 @@ $ kubectl delete -f @samples/sleep/policy/sni-wikipedia.yaml@
 
 ## Monitor the SNI and the source identity, and enforce access policies based on them
 
-Since you enabled mutual TLS between the sidecar proxies and the egress gateway, you can monitor the [service identity](/docs/concepts/what-is-istio/#citadel) of the applications that access external services, and enforce policies
+Since you enabled mutual TLS between the sidecar proxies and the egress gateway, you can monitor the [service identity](/docs/concepts/architecture/#citadel) of the applications that access external services, and enforce policies
 based on the identities of the traffic source.
 In Istio on Kubernetes, the identities are based on
 [Service Accounts](https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/). In this

content/en/news/2019/announcing-1.1/index.md

@@ -28,7 +28,7 @@ As people moved into production with larger clusters running more services at
 higher volume, they hit some scaling and performance issues. The
 [sidecars](/docs/concepts/traffic-management/#sidecars) took too many resources
 and added too much latency. The control plane (especially
-[Pilot](/docs/concepts/traffic-management/#pilot)) was overly
+[Pilot](/docs/concepts/architecture/#pilot)) was overly
 resource hungry.
 
 We’ve done a lot of work to make both the data plane and the control plane more
@@ -42,7 +42,7 @@ teams cannot interfere with each other.
 We have also improved the [multicluster capabilities and usability](/docs/concepts/deployment-models/).
 We listened to the community and improved defaults for traffic control and
 policy. We introduced a new component called
-[Galley](/docs/concepts/what-is-istio/#galley). Galley validates that sweet,
+[Galley](/docs/concepts/architecture/#galley). Galley validates that sweet,
 sweet YAML, reducing the chance of configuration errors. Galley will also be
 instrumental in [multicluster setups](/docs/setup/install/multicluster/),
 gathering service discovery information from each Kubernetes cluster. We are
@@ -252,7 +252,7 @@ concise list of things you should know before upgrading your deployment to Istio
 
 ### Configuration management
 
-- **Galley**. Added [Galley](/docs/concepts/what-is-istio/#galley) as the
+- **Galley**. Added [Galley](/docs/concepts/architecture/#galley) as the
   primary configuration ingestion and distribution mechanism within Istio. It
   provides a robust model to validate, transform, and distribute configuration
   states to Istio components insulating the Istio components from Kubernetes