OCPBUGS-44843 Update guidance on why why you would one way over the other to manage additional networks

Author: kquinn1204

networking/multiple_networks/configuring-additional-network.adoc

@@ -16,31 +16,61 @@ As a cluster administrator, you can configure an additional network for your clu
 * xref:../../networking/multiple_networks/configuring-additional-network.adoc#nw-multus-tap-object_configuring-additional-network[TAP]
 * xref:../../networking/multiple_networks/configuring-additional-network.adoc#configuration-ovnk-additional-networks_configuring-additional-network[OVN-Kubernetes]
 
-[id="{context}_approaches-managing-additional-network"]
+[id="approaches-managing-additional-network_{context}"]
 == Approaches to managing an additional network
 
-You can manage the lifecycle of an additional network by choosing one of the two available approaches. Each approach is mutually exclusive and you can only use one approach for managing an additional network at a time. For either approach, the additional network is managed by a Container Network Interface (CNI) plugin that you configure.
+You can manage the lifecycle of an additional network in {product-title} by using one of two approaches: modifying the Cluster Network Operator (CNO) configuration or applying a YAML manifest. Each approach is mutually exclusive and you can only use one approach for managing an additional network at a time. For either approach, the additional network is managed by a Container Network Interface (CNI) plugin that you configure. The two different approaches are summarized here: 
 
-* Modify the Cluster Network Operator (CNO) configuration: The CNO automatically creates and manages the `NetworkAttachmentDefinition` custom resource definition (CRD). In addition to managing an object lifecycle the CNO ensures a DHCP is available for an additional network that uses a DHCP-assigned IP address.
+* Modifying the Cluster Network Operator (CNO) configuration: Configuring additional networks through CNO is only possible for cluster administrators. The CNO automatically creates and manages the `NetworkAttachmentDefinition` object. By using this approach, you can define `NetworkAttachmentDefinition` objects at install time through configuration of the `install-config`.
 
-* Applying a YAML manifest: You can manage the additional network directly by creating a `NetworkAttachmentDefinition` CRD. This approach allows for the chaining of CNI plugins.
-
-For an additional network, IP addresses are provisioned through an IP Address Management (IPAM) CNI plugin that you configure as part of the additional network. The IPAM plugin supports a variety of IP address assignment approaches including Dynamic Host Configuration Protocol (DHCP) and static assignment.
+* Applying a YAML manifest: You can manage the additional network directly by creating an `NetworkAttachmentDefinition` object. Compared to modifying the CNO configuration, this approach gives you more granular control and flexibility when it comes to configuration. 
 
 [NOTE]
 ====
-When deploying {product-title} nodes with multiple network interfaces on {rh-openstack-first} with OVN Kubernetes, DNS configuration of the additional interface might take precedence over the DNS configuration of the primary interface. In this case, remove the DNS nameservers for the subnet ID that is attached to the additional interface:
+When deploying {product-title} nodes with multiple network interfaces on {rh-openstack-first} with OVN Kubernetes, DNS configuration of the secondary interface might take precedence over the DNS configuration of the primary interface. In this case, remove the DNS nameservers for the subnet ID that is attached to the secondary interface:
 
 [source,terminal]
 ----
 $ openstack subnet set --dns-nameserver 0.0.0.0 <subnet_id>
 ----
 ====
 
-[id="{context}_configuration-additional-network-attachment"]
+[id="ip-address-assignment-for-additional-networks_{context}"]
+== IP address assignment for additional networks
+
+For additional networks, IP addresses can be assigned using an IP Address Management (IPAM) CNI plugin, which supports various assignment methods, including Dynamic Host Configuration Protocol (DHCP) and static assignment.
+
+The DHCP IPAM CNI plugin responsible for dynamic assignment of IP addresses operates with two distinct components:
+
+* *CNI Plugin*: Responsible for integrating with the Kubernetes networking stack to request and release IP addresses.
+* *DHCP IPAM CNI Daemon*: A listener for DHCP events that coordinates with existing DHCP servers in the environment to handle IP address assignment requests. This daemon is _not_ a DHCP server itself.
+
+For networks requiring `type: dhcp` in their IPAM configuration, ensure the following:
+
+* A DHCP server is available and running in the environment. The DHCP server is external to the cluster and is expected to be part of the customer's existing network infrastructure.
+* The DHCP server is appropriately configured to serve IP addresses to the nodes.
+
+In cases where a DHCP server is unavailable in the environment, it is recommended to use the Whereabouts IPAM CNI plugin instead. The Whereabouts CNI provides similar IP address management capabilities without the need for an external DHCP server.
+
+[NOTE]
+====
+Use the Whereabouts CNI plugin when there is no external DHCP server or where static IP address management is preferred. The Whereabouts plugin includes a reconciler daemon to manage stale IP address allocations.
+====
+
+A DHCP lease must be periodically renewed throughout the container's lifetime, so a separate daemon, the DHCP IPAM CNI Daemon, is required. To deploy the DHCP IPAM CNI daemon, modify the Cluster Network Operator (CNO) configuration to trigger the deployment of this daemon as part of the additional network setup.
+
+[role="_additional-resources"]
+.Additional resources
+
+* xref:../../networking/multiple_networks/configuring-additional-network.adoc#nw-multus-dhcp_configuring-additional-network[Dynamic IP address (DHCP) assignment configuration]
+
+* xref:../../networking/multiple_networks/configuring-additional-network.adoc#nw-multus-whereabouts_configuring-additional-network[Dynamic IP address assignment configuration with Whereabouts]
+
+[id="configuration-additional-network-attachment_{context}"]
 == Configuration for an additional network attachment
 
 An additional network is configured by using the `NetworkAttachmentDefinition` API in the `k8s.cni.cncf.io` API group.
+
 [IMPORTANT]
 ====
 Do not store any sensitive information or a secret in the `NetworkAttachmentDefinition` CRD because this information is accessible by the project administration user.
@@ -67,7 +97,7 @@ The configuration for the API is described in the following table:
 
 |====
 
-[id="{context}_configuration-additional-network-cno"]
+[id="configuration-additional-network-cno_{context}"]
 === Configuration of an additional network through the Cluster Network Operator
 
 The configuration for an additional network attachment is specified as part of the Cluster Network Operator (CNO) configuration.
@@ -102,7 +132,7 @@ To prevent namespace issues for the OVN-Kubernetes network plugin, do not name y
 ====
 <4> A CNI plugin configuration in JSON format.
 
-[id="{context}_configuration-additional-network-yaml"]
+[id="configuration-additional-network-yaml_{context}"]
 === Configuration of an additional network from a YAML manifest
 
 The configuration for an additional network is specified from a YAML configuration file, such as in the following example:
@@ -122,7 +152,7 @@ spec:
 <1> The name for the additional network attachment that you are creating.
 <2> A CNI plugin configuration in JSON format.
 
-[id="{context}_configuration-additional-network-types"]
+[id="configuration-additional-network-types_{context}"]
 == Configurations for additional network types
 
 The specific configuration fields for additional networks is described in the following sections.
@@ -163,19 +193,19 @@ include::modules/configuration-ovnk-multi-network-policy.adoc[leveloffset=+3]
 //include::modules/configuring-layer-three-routed-topology.adoc[leveloffset=+3]
 include::modules/configuring-layer-two-switched-topology.adoc[leveloffset=+3]
 
-[id="{context}_ovn-kubernetes-configuration-for-a-localnet-topology"]
+[id="ovn-kubernetes-configuration-for-a-localnet-topology_{context}"]
 ==== Configuration for a localnet topology
 
 // Configuration for a localnet switched topology
 include::modules/configuring-localnet-switched-topology.adoc[tag=localnet-intro]
 
 // Workaround lack of xref in modules
-[id="{context}_configuration-additional-network-types-prerequisites"]
+[id="configuration-additional-network-types-prerequisites_{context}"]
 ===== Prerequisites for configuring OVN-Kubernetes additional network
 
 - The NMState Operator is installed. For more information, see xref:../../networking/networking_operators/k8s-nmstate-about-the-k8s-nmstate-operator.adoc#k8s-nmstate-about-the-k8s-nmstate-operator[Kubernetes NMState Operator].
 
-[id="{context}_configuration-additional-network-interface"]
+[id="configuration-additional-network-interface_{context}"]
 ===== Configuration for an OVN-Kubernetes additional network mapping
 
 // Configuration for a localnet switched topology
@@ -202,7 +232,7 @@ include::modules/nw-multus-configure-dualstack-ip-address.adoc[leveloffset=+2]
 
 [role="_additional-resources"]
 .Additional resources
-* xref:../../networking/multiple_networks/attaching-pod.html#nw-multus-add-pod_attaching-pod[Attaching a pod to an additional network]
+* xref:../../networking/multiple_networks/attaching-pod.adoc#nw-multus-add-pod_attaching-pod[Attaching a pod to an additional network]
 
 // Creating an additional network attachment with the Cluster Network Operator
 include::modules/nw-multus-create-network.adoc[leveloffset=+1]