diff --git a/_docs/concepts/rules-configuration.md b/_docs/concepts/rules-configuration.md
index 65c733b3ef..014d2e1da9 100644
--- a/_docs/concepts/rules-configuration.md
+++ b/_docs/concepts/rules-configuration.md
@@ -132,7 +132,7 @@ Each backend corresponds to a specific version of the destination service,
 where versions can be expressed using _tags_.
 
 If there are multiple registered instances with the specified tag(s),
-they will be routed to based on the [load balancing policy](#loadBalancing) configured for the service,
+they will be routed to based on the load balancing policy configured for the service,
 or round-robin by default.
 
 For example, the following rule will route 25% of traffic for the "reviews" service to instances with
diff --git a/_docs/concepts/service-model.md b/_docs/concepts/service-model.md
index d64c17734b..787dde1d07 100644
--- a/_docs/concepts/service-model.md
+++ b/_docs/concepts/service-model.md
@@ -24,7 +24,7 @@ way to subdivide service instances by versions (`v1`, `v2`) or environment
 versions: they could be iterative changes to the same service, deployed in
 different environments (prod, staging, dev, etc.). Common scenarios where
 this occurs include A/B testing, canary rollouts, etc. Istio's [traffic
-management rules - TBD]() can refer to the service versions, to provide
+management rules](./rules-configuration.html) can refer to the service versions, to provide
 additional control over traffic between services.
 
 ## Communication between services
diff --git a/_docs/concepts/traffic-management-overview.md b/_docs/concepts/traffic-management-overview.md
index 57af673c63..3693e504aa 100644
--- a/_docs/concepts/traffic-management-overview.md
+++ b/_docs/concepts/traffic-management-overview.md
@@ -30,9 +30,9 @@ before beginning a canary deployment.
 Decoupling traffic flow from infrastructure scaling allows Istio to provide
 a variety of traffic management features that reside outside the
 application code. Features include dynamic
-[request routing](./request-routing.html) for A/B testing, canary releases,
-gradual rollouts, etc., [failure recovery (TBD)](./handling-failures.html)
+[request routing](../tasks/request-routing.html) for A/B testing, canary releases,
+gradual rollouts, etc., [failure recovery](./handling-failures.html)
 using timeouts, retries, circuit breakers, and finally
-[fault injection (TBD)](./fault-injection.html) to test compatibility of
+[fault injection](./fault-injection.html) to test compatibility of
 failure recovery policies across services. These capabilities are realized
 through the Envoy sidecars/proxies deployed across the service mesh.