reconstruct the site to reflect the big-ip next integration

docs/Design/bipnext.md

@@ -0,0 +1,43 @@
+# Overview [WIP]
+
+## What is BIG-IP Next
+
+At its core, it’s still the same BIG-IP that F5 customers know and trust, simply designed and
+rearchitected for the future. BIG-IP Next is the next generation BIG-IP software built to offer
+greater automation opportunities, scalability, and ease-of-use for organizations running
+applications on-premises, in the cloud, or out at the edge. Powerful declarative APIs are the
+foundation for BIG-IP Next’s API-first design, making it faster and easier for DevOps, NetOps,
+and other BIG-IP-reliant teams to manage and automate their BIG-IP deployments.
+
+A completely rearchitected software layer built on a modern framework provides the basis for
+significantly improved control plane scale and performance, reduced cloud footprint for lower
+operational costs, and rapid instance upgrades. Carrying forward the comprehensive suite
+of advanced BIG-IP functionality developed over the past 20 years, BIG-IP Next continues
+to deliver everything from application security and access controls to local and global traffic
+management—and availability across the same breadth of deployment and consumption
+models as its predecessor.
+
+## What is BIG-IP Next Kubernetes GatewayAPI Controller
+
+BIG-IP Next Kubernetes GatewayAPI Controller ("Controller next" in short) is one of GatewayAPI downstream [implementations](https://gateway-api.sigs.k8s.io/implementations/){:target="_blank"}.
+
+The "Controller Next" is responsible for resolving 2 problems,
+
+* Automatical application deliveries on downstream BIG-IP Next instance(s).
+* Network connectivity setup between Kubernetes CNI and BIG-IP Next(s) traffic network.
+
+## Resource Monitoring
+
+Like all other CRD implementations, the Controller monitors Kubernetes GatewayAPI CRD resources (gateway.networking.k8s.io/v1beta1) and converts them to BIG-IP Next-related configurations for deploying to BIG-IP Next devices.
+
+The Controller connects to the upstream Kubernetes, monitors Gateway API updating events from the cluster through the list-watch mechanism. The mechanism was encapsulated in `client-go`(k8s.io/client-go) and `controller-runtime`(sigs.k8s.io/controller-runtime).
+
+In order to access various necessary resources of Kubernetes, we need to use specific `ServiceAccount` and `ClusterRole` that have specific permissions. Please refer to [installation guide](../guides/getstarted.md) for permission details.
+
+## Resource Mapping
+
+TODO
+
+
+
+We are actively work on the integration of BIG-IP Next, will update. If you want to learn what is BIG-IP Next, kindly please click [here](https://www.f5.com/pdf/products/an-introduction-to-big-ip-next-f5s-next-generation-big-ip-software.pdf).

docs/Use-Cases/grpc-routing.md

@@ -0,0 +1,3 @@
+## gRPC routing
+
+*Experimental in gateway api v0.5.1, will be supported in future.*

docs/Use-Cases/http-redirect-rewrite.md

@@ -0,0 +1,94 @@
+## HTTP path redirects and rewrites
+
+`HTTPRoute` can be used to redirect clients' request or rewrite the paths sent to the backends using `filters`.
+
+In this page, we will show how to use the `filters` to do the redirect or rewrite.
+
+We ignore the configuration of `GatewayClass` and `Gateway`, and directly show the configurations of different `HTTPRoute` resources.
+
+### Redirects
+
+
+```yaml
+---
+
+apiVersion: gateway.networking.k8s.io/v1beta1
+kind: HTTPRoute
+metadata:
+  name: test-filter-requestredirect
+spec:
+  parentRefs:
+  - name: gateway
+    sectionName: http
+  hostnames:
+  - gateway.test.automation
+  rules:
+  - filters:
+      - type: RequestRedirect
+        requestRedirect:
+          scheme: https
+          hostname: www.example.com
+          # path:     -> experimental in v0.5.1
+          #   type: ReplaceFullPath
+          #   replaceFullPath: /fake
+          port: 443
+          statusCode: 301
+    backendRefs:
+    - name: tea
+      port: 80
+```
+
+In this `HTTPRoute` configuration, when we access `http://gateway.test.automation`, the traffic will be redirect to `https://www.example.com/`:
+
+```shell
+$ curl 10.250.18.119 -H "Host: gateway.test.automation" -v
+*   Trying 10.250.18.119:80...
+* Connected to 10.250.18.119 (10.250.18.119) port 80 (#0)
+> GET / HTTP/1.1
+> Host: gateway.test.automation
+> User-Agent: curl/7.79.1
+> Accept: */*
+>
+* Mark bundle as not supporting multiuse
+* HTTP 1.0, assume close after body
+< HTTP/1.0 301 Moved Permanently
+< Location: https://www.example.com:443/
+< Server: BigIP
+* HTTP/1.0 connection set to keep alive!
+< Connection: Keep-Alive
+< Content-Length: 0
+<
+* Connection #0 to host 10.250.18.119 left intact
+```
+
+As shown here, the virtual responses `< HTTP/1.0 301 Moved Permanently`.
+
+### Rewrites
+
+*Experimental in gateway api v0.5.1, will be supported in future.*
+
+```yaml
+# ---
+
+# apiVersion: gateway.networking.k8s.io/v1beta1
+# kind: HTTPRoute
+# metadata:
+#   name: test-filter-urlrewrite
+# spec:
+#   parentRefs:
+#   - name: gateway
+#     sectionName: http
+#   hostnames:
+#   - "cafe.example.com"
+#   rules:
+#   - filters:
+#       - type: URLRewrite
+#         urlRewrite:
+#           hostname: www.example.com
+#           path: 
+#             type: ReplaceFullPath
+#             replaceFullPath: /fake
+#     backendRefs:
+#     - name: tea
+#       port: 80
+```

docs/Use-Cases/http-routing.md

@@ -0,0 +1,161 @@
+## HTTP Routing
+
+In this scenario, based on [Simple Gateway](./simple-gateway.md), we demonstrate the process of binding multiple httproutes in one gateway to forward traffic with different characteristics, to different backend servers.
+
+In this page, we ignore the configuration of `GatewayClass` and `Gateway`, and directly show the configurations of different `HTTPRoute` resources.
+
+### Request header based matching
+
+```yaml
+---
+
+apiVersion: gateway.networking.k8s.io/v1beta1
+kind: HTTPRoute
+metadata:
+  name: test-match-header
+spec:
+  parentRefs:
+    - name: gateway
+      sectionName: http
+  hostnames:
+    - gateway.test.automation
+  rules:
+    - matches:
+        - headers:
+            - name: test
+              value: automation
+      backendRefs:
+        - name: test-service
+          port: 80
+```
+
+When the domain name of the request is `gateway.test.automation` and the request header contains `test == automation`, the traffic is forwarded to the `test-service` service with port 80.
+
+### Request method based matching
+
+```yaml
+---
+
+apiVersion: gateway.networking.k8s.io/v1beta1
+kind: HTTPRoute
+metadata:
+  name: test-match-method
+spec:
+  parentRefs:
+    - name: gateway
+      sectionName: http
+  hostnames:
+    - gateway.test.automation
+  rules:
+    - matches:
+        - method: GET
+        - method: OPTIONS
+      backendRefs:
+        - name: test-service
+          port: 80
+```
+
+When the domain name is `gateway.test.automation` and the request method is `GET` or `OPTIONS`, the request is forwarded to the `test-service` service with port 80.
+
+### Request path based matching
+
+```yaml
+---
+
+apiVersion: gateway.networking.k8s.io/v1beta1
+kind: HTTPRoute
+metadata:
+  name: test-match-path
+spec:
+  parentRefs:
+    - name: gateway
+      sectionName: http
+  hostnames:
+    - gateway.test.automation
+  rules:
+    - matches:
+        - path:
+            type: PathPrefix
+            value: /path-test
+      backendRefs:
+        - name: test-service
+          port: 80
+```
+
+When the request domain name is `gateway.test.automation` and the request path is `/path-test`, the request is forwarded to the `test-service` service with port 80.
+
+### Request parameter based matching
+
+```yaml
+---
+
+apiVersion: gateway.networking.k8s.io/v1beta1
+kind: HTTPRoute
+metadata:
+  name: test-query-params
+spec:
+  parentRefs:
+    - name: gateway
+      sectionName: http
+  hostnames:
+    - gateway.test.automation
+  rules:
+    - matches:
+      - queryParams:
+        - name: test
+          value: automation
+      backendRefs:
+      - name: test-service
+        port: 80
+```
+
+When the request domain name is `gateway.test.automation`, and the request parameters contain `?test=automation`, the request is forwarded to the `test-service` service with port 80.
+
+### Multiple matches in a HTTPRoute
+
+```yaml
+---
+
+apiVersion: gateway.networking.k8s.io/v1beta1
+kind: HTTPRoute
+metadata:
+  name: test-multiple-rules
+spec:
+  parentRefs:
+    - name: gateway
+      sectionName: http
+  hostnames:
+    - gateway.test.automation
+  rules:
+    - matches:
+      - queryParams:
+          - name: test
+            value: automation
+        path:
+          type: PathPrefix
+          value: /path-test
+      backendRefs:
+        - name: test-service1
+          port: 80
+    - matches:
+      - queryParams:
+        - name: test
+          value: automation
+      - path:
+          type: PathPrefix
+          value: /path-test
+      backendRefs:
+        - name: test-service2
+          port: 80
+    - backendRefs:
+        - name: test-service3
+          port: 80
+```
+
+When the request domain name is `gateway.test.automation`, and
+
+* If the path of the request is `/path-test`, **AND** the request parameters contain `?test=automation`, the request will be forwarded to the `test-service1` service, port 80.
+
+* If the path of the request is `/path-test`, **OR** the request parameters contain `?test=automation`, *(only one of the 2 conditions)*, the request will be forwarded to the `test-service2` service, port 80.
+
+* In other cases, it is forwarded to the `test-service3` service, port 80.

docs/Use-Cases/multiple-ns.md

@@ -0,0 +1,3 @@
+## Cross-Namespace routing
+
+*Supported from bigip-kubernetes-gateway v0.0.5.*