Bring IPs allocation and conneciton forwarding into about.mdx

Author: RebeccaTamachiro

src/content/docs/smart-shield/concepts/connection-reuse.mdx

@@ -11,4 +11,8 @@ Smart Shield leverages Cloudflare's optimized infrastructure to package multiple
 
 ## About connection reuse
 
-<Render file="connection-reuse" product="aegis" />
+<Render file="connection-reuse" product="aegis" />
+
+## Egress IPs allocation
+
+Connection reuse and connection coalescing are also considered when allocating your [Dedicated CDN Egress IPs](/smart-shield/configuration/dedicated-egress-ips/).

src/content/docs/smart-shield/configuration/dedicated-egress-ips/about.mdx

@@ -8,6 +8,8 @@ head:
     content: How Dedicated CDN Egress IPs work
 ---
 
+import { Render } from "~/components";
+
 When you use Cloudflare [as a reverse proxy](/fundamentals/concepts/how-cloudflare-works/#how-cloudflare-works-as-a-reverse-proxy), [Cloudflare's global network](https://www.cloudflare.com/network/) sits between client requests and your origin servers.
 
 ```mermaid
@@ -17,6 +19,8 @@ flowchart LR
         A[Client] <--> B((Cloudflare))<--> C[(Origin server)]
 ```
 
+## Egress IPs
+
 Zooming in to what happens as a request routes through Cloudflare, you can consider two parts of the process: ingress and egress.
 
 ```mermaid
@@ -31,5 +35,126 @@ Ingress refers to the data center where the client request lands on, based on In
 Traditionally, Cloudflare maintains a very large pool of egress IPs that are used by all Cloudflare customers and are [publicly documented](https://www.cloudflare.com/ips/). With Dedicated CDN Egress IPs, Cloudflare connects to your origin using IPs that are reserved for you.
 
 :::note
-Each dedicated egress pool can consist of either IPs from a [BYOIP prefix](/byoip/) or Cloudflare-leased IPs. A single dedicated egress pool cannot contain both BYOIPs and leased IPs.
+Each dedicated CDN egress IP pool can consist of either IPs from a [BYOIP prefix](/byoip/) or Cloudflare-leased IPs. A single dedicated CDN egress IP pool cannot contain both BYOIPs and leased IPs.
+:::
+
+## IPs allocation
+
+Dedicated CDN Egress IPs support both IPv4 and IPv6 addresses.
+
+IPv6 address ranges are deployed globally, meaning your dedicated IPv6 addresses can be used for connections from Cloudflare to your origin servers across all Cloudflare data centers.
+
+:::note[China exception]
+Dedicated CDN Egress IPs are currently **not** available in the [Cloudflare China Network](/china-network/).
 :::
+
+For IPv4 addresses, you should work with your account team to choose the locations where each IP should be deployed. Ideally, your dedicated IPv4 addresses should be placed near your origin servers and adjusted to the amount of traffic expected for each region.
+
+Refer to [connection forwarding](#connection-forwarding) to understand how requests are processed when reaching different Cloudflare data centers.
+
+### Connections to your origin
+
+<Render file="concurrent-connections-explainer" product="aegis" />
+
+Dedicated CDN Egress IPs also benefit from [connection reuse and connection coalescing](/smart-shield/concepts/connection-reuse/).
+
+GraphQL Analytics API allows you to get visibility over [IPs utilization](/smart-shield/configuration/dedicated-egress-ips/ips-utilization/).
+
+### Regional services
+
+If you are using [Regional Services](/data-localization/regional-services/), you should take this into consideration when allocating dedicated IPv4 addresses. Traffic will egress from the specified locations as long as you have Dedicated CDN Egress IPs provisioned in those locations.
+
+## Connection forwarding
+
+Since IPv6 address ranges are deployed globally, no forwarding is needed.
+
+For IPv4 traffic, based on [IPs allocation](#ips-allocation), not all egress data centers will have access to an applicable dedicated CDN egress IP.
+
+Dedicated CDN egress IPs do not forward to another location in response to traffic spikes. Instead, each IPv4 can be split across up to four locations, where some of these locations may have multiple data centers. IP capacity in each data center can also be adjusted in accordance with the amount of traffic that reaches each location.
+
+After a request reaches Cloudflare on an ingress data center, and the cache service sends a request for the egress router to connect to your origin, the following scenarios are possible.
+
+### Traffic can egress from the same server
+
+If the server running the egress router has access to an applicable dedicated CDN egress IP, traffic egresses from that server.
+
+```mermaid
+flowchart LR
+        accTitle: Dedicated CDN Egress IPs and connection forwarding
+        accDescr: Diagram showing IPv4 connection forwarding for Dedicated CDN Egress IPs - Same data center.
+        A[Client]
+        subgraph Data center A
+        X[(Cache service)] --> B[(Egress router <br/> <small>*has applicable IP</small>)]
+        end
+        C[(Origin server)]
+
+        A --ingress--> X
+        B --egress--> C
+```
+
+### Connection forwarding is needed
+
+If the server does not have access to an applicable IP, the following options are checked and the first that is possible will take place:
+
+* Another server in the same data center has access to an applicable IP and the connection is forwarded to that server.
+
+```mermaid
+flowchart LR
+        accTitle: Dedicated CDN Egress IPs and connection forwarding
+        accDescr: Diagram showing IPv4 connection forwarding for Dedicated CDN Egress IPs - Same data center.
+        A[Client]
+        subgraph Data center A
+        X[(Cache service)] --> B[(Egress router <br/> <small>*no applicable IP</small>)]
+        B --> Y[(Egress server <br/> <small>*has applicable IP</small>)]
+        end
+        C[(Origin server)]
+
+        A --ingress--> X
+        Y --egress--> C
+```
+
+* Another data center in the same location has access to an applicable IP and the connection is forwarded to that data center.
+
+```mermaid
+flowchart LR
+        accTitle: Dedicated CDN Egress IPs and connection forwarding
+        accDescr: Diagram showing IPv4 connection forwarding for Dedicated CDN Egress IPs - Different data center.
+        A[Client]
+        subgraph Location 1
+        subgraph Data center A
+        X[(Cache service)] --> B[(Egress router <br/> <small>*no applicable IP</small>)]
+        end
+        subgraph Data center B
+        B --> Y[(Egress server <br/> <small>*has applicable IP</small>)]
+        end
+        end
+        C[(Origin server)]
+
+
+        A --ingress--> X
+        Y --egress--> C
+```
+
+* Another data center in a different location has access to an applicable IP. The closest location is selected and connection is forwarded to that location.
+
+```mermaid
+flowchart LR
+        accTitle: Dedicated CDN Egress IPs and connection forwarding
+        accDescr: Diagram showing IPv4 connection forwarding for Dedicated CDN Egress IPs - Different location.
+        A[Client]
+        subgraph Location 1
+          subgraph Data center A
+          X[(Cache service)] --> B[(Egress router <br/> <small>*no applicable IP</small>)]
+          end
+        end
+        subgraph Location 2
+          subgraph Data center C
+            B --> Y[(Egress server <br/> <small>*has applicable IP</small>)]
+          end
+        end
+        C[(Origin server)]
+
+
+        A --ingress--> X
+        Y --egress--> C
+```

src/content/partials/aegis/connection-reuse.mdx

@@ -8,6 +8,6 @@ Implemented by HTTP/1.1, connection reuse describes multiple requests passing th
 
 For example, when a connection is initiated for `shop.example.com`, several embedded subresources may be requested - CSS, image files, advertisement, etc. This can mean hundreds of requests just for the website to load. Instead of having a one to one ratio of request per connection, a single connection is used for multiple requests.
 
-With HTTP/2, requests can use the same connection even if they are for different domains.
+With HTTP/2, requests can use the same connection even if they are for different domains (also known as connection coalescing).
 
 For example, a connection initiated for `shop.example.com` can be used for requests for `blog.example.com` as well - as long as the requests have the same destination IP:port and the server TLS certificate is authoritative for both hostnames.