udn, virt: list multus default network alternative

Signed-off-by: Miguel Duarte Barroso <[email protected]>

enhancements/network/primary-user-defined-networks-for-virtualization-workloads.md

@@ -184,6 +184,10 @@ All the other
 to support live-migration was already implemented as part of the epic
 implementing UDN.
 
+We evaluate an alternative for this in the
+[Using multus default network annotation](#using-multus-default-network-annotation)
+section.
+
 ### Allow user to configure the VMs interface desired IP address
 
 To allow the user to specify the IP address for the workload we plan on adding
@@ -599,3 +603,21 @@ A variation of this option would be if the user annotated the VM directly with
 the IPs they want to have available on the primary UDN interface - this way,
 OpenShift Virtualization would create the `IPAMClaim` on behalf of the user,
 requesting whose IPs in its `IPAMClaim.Spec.IPRequests` attribute.
+
+### Using multus default network annotation
+We could use the
+[multus default network annotation](https://github.com/k8snetworkplumbingwg/multus-cni/blob/master/docs/configuration.md#specify-default-cluster-network-in-pod-annotations)
+to pass extra / override attributes for the primary UDN network.
+
+The user would need to define the network-selection-element on the pod, and it
+would need to point to the `IPAMClaim` object, as done for secondary networks.
+
+While this would be a native way to integrate with the rest of the persistent
+IPs feature, it would be a clumsy flow for primary UDNs, since the user would
+be expected to use network selection elements to configure the primary UDN.
+
+Furthermore, we currently not allow primary UDNs to be attached via network 
+selection elements. We would need to break this convention.
+
+This route could be interesting in the future though, since we expect this to
+become the way to request SR-IOV resources for primary UDNs.