OSDOCS-16284: Added OVNK and SDNstatements tto nw-networkpolicy-about.adoc

Author: dfitzmau

modules/nw-networkpolicy-about.adoc

@@ -6,12 +6,13 @@
 [id="nw-networkpolicy-about_{context}"]
 = About network policy
 
-In a cluster using a network plugin that supports Kubernetes network policy, network isolation is controlled entirely by `NetworkPolicy` objects.
-In {product-title} {product-version}, OpenShift SDN supports using network policy in its default network isolation mode.
+In a cluster that uses a network plugin that supports a Kubernetes network policy, `NetworkPolicy` objects controls network isolation. In {product-title} {product-version}, OpenShift SDN supports using network policy in its default network isolation mode.
 
 [WARNING]
 ====
-* A network policy does not apply to the host network namespace. Pods with host networking enabled are unaffected by network policy rules. However, pods connecting to the host-networked pods might be affected by the network policy rules.
+* On OpenShift-SDN, a network policy does not apply to the host network namespace. Network policy rules do not impact pods configured with host networking enabled. Network policy rules might impact pods connected to host-networked pods.
+
+* On Openshift-OVN-Kubernetes, a network policy manages traffic from host subnets separately from traffic on pod networks. Before any other network policies can affect pods with host networking enabled, you must explicitly allow those pods in your network policy rules. If a namespace has any network policy applied, traffic originating from system components, such as `openshift-ingress` or `openshift-kube-apiserver`,  get dropped by default; You must explicitly enable this traffic to allow it through.
 
 * Using the `namespaceSelector` field without the `podSelector` field set to `{}` will not include `hostNetwork` pods. You must use the `podSelector` set to `{}` with the `namespaceSelector` field in order to target `hostNetwork` pods when creating network policies.
 

modules/nw-ovn-kubernetes-live-migration-about.adoc

@@ -5,7 +5,7 @@
 [id="nw-ovn-kubernetes-live-migration-about_{context}"]
 = Limited live migration to the OVN-Kubernetes network plugin overview
 
-The limited live migration method is the process in which the OpenShift SDN network plugin and its network configurations, connections, and associated resources, are migrated to the OVN-Kubernetes network plugin without service interruption. It is available for {product-title}, and is the preferred method for migrating from OpenShift SDN to OVN-Kubernetes. In the event that you cannot perform a limited live migration, you can use the offline migration method.
+The limited live migration method is the process in which the OpenShift SDN network plugin and its network configurations, connections, and associated resources, are migrated to the OVN-Kubernetes network plugin without service interruption. It is available for {product-title}, and is the preferred method for migrating from OpenShift SDN to OVN-Kubernetes. If you cannot perform a limited live migration, you can use the offline migration method.
 
 [IMPORTANT]
 ====
@@ -98,3 +98,5 @@ During the limited live migration, both OVN-Kubernetes and OpenShift SDN run in
 After migration, manual verification of RBAC resources is required. For information about setting the `aggregate-to-admin` ClusterRole after migration, see the example in link:https://access.redhat.com/solutions/6117301[How to allow project admins to manage Egressfirewall resources in RHOCP4].
 
 * When a cluster depends on static routes or routing policies in the host network so that pods can reach some destinations, users should set `routingViaHost` spec to `true` and `ipForwarding` to `Global` in the `gatewayConfig` object before the migration. This will offload routing decision to host kernel. For more information, see link:https://access.redhat.com/solutions/7070870[Recommended practice to follow before Openshift SDN network plugin migration to OVNKubernetes plugin] (Red Hat Knowledgebase) and, see step five in "Checking cluster resources before initiating the limited live migration".
+
+* To prevent traffic flow issues, check existing network policies in any namespaces that host applications that rely on system components. If a policy exists, enable traffic that originates from `openshift-ingress` or `openshift-kube-apiserver` system services to prevent the default setting from blocking this traffic.

modules/nw-ovn-kubernetes-migration-about.adoc

@@ -89,9 +89,9 @@ While the OVN-Kubernetes network plugin implements many of the capabilities pres
 
 * If your `openshift-sdn` cluster with Precision Time Protocol (PTP) uses the User Datagram Protocol (UDP) for hardware time stamping and you migrate to the OVN-Kubernetes plugin, the hardware time stamping cannot be applied to primary interface devices, such as an Open vSwitch (OVS) bridge. As a result, UDP version 4 configurations cannot work with a `br-ex` interface.
 
-* Like OpenShift SDN, OVN-Kubernetes resources require `ClusterAdmin` privileges. Migrating from OpenShift SDN to OVN-Kubernetes does not automatically update role-base access control (RBAC) resources. OpenShift SDN resources granted to a project administrator through the `aggregate-to-admin` `ClusterRole` must be manually reviewed and adjusted, as these changes are not included in the migration process.
-+
-After migration, manual verification of RBAC resources is required.
+* Like OpenShift SDN, OVN-Kubernetes resources require `ClusterAdmin` privileges. Migrating from OpenShift SDN to OVN-Kubernetes does not automatically update role-base access control (RBAC) resources. OpenShift SDN resources granted to a project administrator through the `aggregate-to-admin` `ClusterRole` must be manually reviewed and adjusted, as these changes are not included in the migration process. After migration, manual verification of RBAC resources is required.
+
+* To prevent traffic flow issues, check existing network policies in any namespaces that host applications that rely on system components. If a policy exists, enable traffic that originates from `openshift-ingress` or `openshift-kube-apiserver` system services to prevent the default setting from blocking this traffic.
 
 The following sections highlight the differences in configuration between the aforementioned capabilities in OVN-Kubernetes and OpenShift SDN network plugins.