OSDOCS-13291-main:removes TP for UDN

Author: JoeAldinger

networking/multiple_networks/primary_networks/about-user-defined-networks.adoc

@@ -6,8 +6,6 @@ include::_attributes/common-attributes.adoc[]
 
 toc::[]
 
-:featurename: `UserDefinedNetwork`
-include::snippets/technology-preview.adoc[]
 
 Before the implementation of user-defined networks (UDNs) in the default the OVN-Kubernetes CNI plugin for {product-title}, the Kubernetes Layer 3 topology was supported as the primary network, or _main_ network, to where all pods attach. The Kubernetes design principle requires that all pods communicate with each other by their IP addresses, and Kubernetes restricts inter-pod traffic according to the Kubernetes network policy. While the Kubernetes design is useful for simple deployments, the Layer 3 topology restricts customization of primary network segment configurations, especially for modern multi-tenant deployments.
 
@@ -22,25 +20,14 @@ image::527-OpenShift-UDN-isolation-012025.png[The namespace isolation concept in
 Support for the Localnet topology on both primary and secondary networks will be added in a future version of {product-title}.
 ====
 
-Unlike a network attachment definition (NAD), which is only namespaced scope, a cluster administrator can use a UDN to create and define additional networks that span multiple namespaces at the cluster level by leveraging the `ClusterUserDefinedNetwork` custom resource (CR). Additionally, a cluster administrator or a cluster user can use a UDN to define additional networks at the namespace level with the `UserDefinedNetwork` CR. 
+A cluster administrator can use a user-defined network to create and define additional networks that span multiple namespaces at the cluster level by leveraging the `ClusterUserDefinedNetwork` custom resource (CR). Additionally, a cluster administrator or a cluster user can use a user-defined network to define additional networks at the namespace level with the `UserDefinedNetwork` CR.
 
 The following diagram shows tenant isolation that a cluster administrator created by defining a `ClusterUserDefinedNetwork` (CR) for each tenant. This network configuration allows a network to span across many namespaces. In the diagram, the `udn-1` disconnected network selects `namespace-1` and `namespace-2`, while the `udn-2` disconnected network selects `namespace-3` and `namespace-4`. A tenant acts as a disconnected network that is isolated from other tenants' networks. Pods from a namespace can communicate with pods in another namespace only if those namespaces exist in the same tenant network.
 
 image::528-OpenShift-multitenant-0225.png[The tenant isolation concept in a user-defined network (UDN)]
 
 The following sections further emphasize the benefits and limitations of user-defined networks, the best practices when creating a `ClusterUserDefinedNetwork` or `UserDefinedNetwork` custom resource, how to create the custom resource, and additional configuration details that might be relevant to your deployment.
 
-// Looks like this may be out for 4.17, but in for 4.18 as of 8/19/24
-//. Ingress and egress support
-//+
-//* **Support for ingress and egress traffic**: Cluster ingress and egress traffic is supported for both primary and secondary networks.
-//* **Support for ingress and egress features**: User-defined networks support support the following ingress and egress features:
-//+
-//** EgressQoS
-//** EgressService
-//** EgressIP
-//** Load balancer and NodePort services, and services with external IPs.
-
 //benefits of UDN
 include::modules/nw-udn-benefits.adoc[leveloffset=+1]