diff --git a/docs/gitbook/how-it-works.md b/docs/gitbook/how-it-works.md
index fda9db563..4331cd09c 100644
--- a/docs/gitbook/how-it-works.md
+++ b/docs/gitbook/how-it-works.md
@@ -327,6 +327,22 @@ With the above configuration Flagger will run conformance and load tests on the
 If the metrics analysis succeeds, live traffic will be switched from the old version to the new one when the
 canary is promoted.
 
+The blue/green deployment strategy is supported for all service mesh providers.
+
+Blue/Green rollout steps for service mesh:
+* scale up the canary (green)
+* run conformance tests for the canary pods
+* run load tests and metric checks for the canary pods
+* route traffic to canary
+* promote canary spec over primary (blue)
+* wait for primary rollout
+* route traffic to primary
+* scale down canary
+
+After the analysis finishes, the traffic is routed to the canary (green) before triggering the primary (blue)
+rolling update, this ensures a smooth transition to the new version avoiding dropping in-flight requests during
+the Kubernetes deployment rollout.
+
 ### HTTP Metrics
 
 The canary analysis is using the following Prometheus queries:
diff --git a/docs/gitbook/usage/blue-green.md b/docs/gitbook/usage/blue-green.md
index e4ed22098..e211ba7e4 100644
--- a/docs/gitbook/usage/blue-green.md
+++ b/docs/gitbook/usage/blue-green.md
@@ -4,6 +4,7 @@ This guide shows you how to automate Blue/Green deployments with Flagger and Kub
 
 For applications that are not deployed on a service mesh, Flagger can orchestrate Blue/Green style deployments 
 with Kubernetes L4 networking.
+When using a service mesh blue/green can be used as specified [here](https://docs.flagger.app/how-it-works#blue-green-deployments).
 
 ![Flagger Blue/Green Stages](https://raw.githubusercontent.com/weaveworks/flagger/master/docs/diagrams/flagger-bluegreen-steps.png)