Update NGF service docs again

content/includes/ngf/installation/expose-nginx-gateway-fabric.md

@@ -4,50 +4,4 @@ weight: 300
 nd-docs: "DOCS-1427"
 ---
 
-When a Gateway resource is created, the NGINX Gateway Fabric control plane will provision an NGINX service in the same namespace as the Gateway. By default, this is a LoadBalancer service. This is not the same service that is deployed when NGINX Gateway Fabric is first installed. The NGINX Gateway Fabric control plane has its own ClusterIP service for internal communication with the NGINX data planes.
-
-There are two options for accessing the NGINX service depending on the type of LoadBalancer service you chose during installation:
-
-- If the Service type is `NodePort`, Kubernetes will randomly allocate two ports on every node of the cluster.
-  To access NGINX, use an IP address of any node of the cluster along with the two allocated ports.
-
-  {{< call-out "tip" >}} Read more about the type NodePort in the [Kubernetes documentation](https://kubernetes.io/docs/concepts/services-networking/service/#type-nodeport). {{< /call-out >}}
-
-- If the Service type is `LoadBalancer`:
-
-  - For GCP or Azure, Kubernetes will allocate a cloud load balancer for load balancing the NGINX pods.
-    Use the public IP of the load balancer to access NGINX.
-  - For AWS, Kubernetes will allocate a Network Load Balancer (NLB) in TCP mode with the PROXY protocol enabled to pass
-    the client's information (the IP address and the port).
-
-  Use the public IP of the load balancer to access NGINX. The NGINX Service exists in the same namespace that you deployed your Gateway in, and its name is `<gatewayName-gatewayClassName>`. To get the public IP which is reported in the `EXTERNAL-IP` column:
-
-  - For GCP or Azure, run:
-
-    ```shell
-    kubectl get svc <gatewayName-gatewayClassName> -n <gateway-namespace>
-    ```
-
-  - In AWS, the NLB (Network Load Balancer) DNS name will be reported by Kubernetes instead of a public IP. To get the DNS name, run:
-
-    ```shell
-    kubectl get svc <gatewayName-gatewayClassName> -n <gateway-namespace>
-    ```
-
-    {{< call-out "note" >}} We recommend using the NLB DNS whenever possible, but for testing purposes, you can resolve the DNS name to get the IP address of the load balancer:
-
-  ```shell
-  nslookup <dns-name>
-  ```
-
-    {{< /call-out >}}
-
-  {{< call-out "tip" >}} Learn more about type LoadBalancer in the [Kubernetes documentation](https://kubernetes.io/docs/concepts/services-networking/service/#type-loadbalancer).
-
-  For AWS, additional options regarding an allocated load balancer are available, such as its type and SSL
-  termination. Read the [Kubernetes documentation](https://kubernetes.io/docs/concepts/services-networking/service/#type-loadbalancer) to learn more.
-  {{< /call-out >}}
-
-NGINX Gateway Fabric uses the created service to update the **Addresses** field in the **Gateway Status** resource. Using a **LoadBalancer** service sets this field to the IP address and/or hostname of that service. Without a service, the pod IP address is used.
-
-This gateway is associated with NGINX Gateway Fabric through the **gatewayClassName** field. The default installation of NGINX Gateway Fabric creates a **GatewayClass** with the name **nginx**. NGINX Gateway Fabric will only configure gateways with a **gatewayClassName** of **nginx** unless you change the name via the `--gatewayclass` [command-line flag]({{< ref "/ngf/reference/cli-help.md#controller">}}).
+The Service that is provisioned when NGINX Gateway Fabric is first installed is a ClusterIP Service used only for internal communication between the control plane and data planes. To deploy NGINX itself and get a LoadBalancer Service, you now need to [create a Gateway]({{< ref "/ngf/install/deploy-data-plane.md" >}}).

content/ngf/install/deploy-data-plane.md

@@ -13,7 +13,7 @@ This document describes how to use a Gateway to deploy the NGINX data plane, and
 
 [A Gateway](https://gateway-api.sigs.k8s.io/concepts/api-overview/#gateway) is used to manage all inbound requests, and is a key Gateway API resource.
 
-When a Gateway is attached to a GatewayClass associated with NGINX Gateway Fabric, it creates a Service and an NGINX deployment. This forms the NGINX data plane, handling requests.
+When a Gateway is attached to a GatewayClass associated with NGINX Gateway Fabric, it creates a Service and an NGINX deployment in the same namespace as the Gateway. This forms the NGINX data plane, handling requests.
 
 A single GatewayClass can have multiple Gateways: each Gateway will create a separate Service and NGINX deployment.
 
@@ -93,10 +93,10 @@ kubectl get services
 ```
 ```text
 NAME         TYPE            CLUSTER-IP      EXTERNAL-IP   PORT(S)        AGE
-cafe-nginx   LoadBalancer    10.96.125.117   <pending>     80:30180/TCP   5m2s
+cafe-nginx   LoadBalancer    10.96.125.117   192.0.2.1   80:30180/TCP   5m2s
 ```
 
-The Service type can be changed, as explained in the next section.
+The Service type can be changed, as explained in the next section. NGINX Gateway Fabric uses the created Service to update the **Addresses** field in the **Gateway Status** resource. Using a **LoadBalancer** Service sets this field to the IP address and/or hostname of that service. Without a Service, the pod IP address is used.
 
 ## Modify provisioned NGINX instances
 
@@ -170,7 +170,7 @@ Use `kubectl edit` to modify the default NginxProxy and insert the following und
 type: NodePort
 ```
 
-After saving the changes, use `kubectl get` on the service, and you should see the service type has changed to `LoadBalancer`.
+After saving the changes, use `kubectl get` on the service, and you should see the service type has changed to `NodePort`.
 
 ```shell
 kubectl get service cafe-nginx