Unicast flooding is the result of switch receiving a unicast frame, but not having an entry for the destination MAC address in its CAM table.
When a switch receives such frame, it will flood it out of all ports, hence the name unicast flooding.
There are a few scenarios where this is common:
1. As stated in 1.1.c (iii)
Asymmetric routing can cause unicast flooding of traffic in very specialized conditions (worse if it’s one way UDP traffic).
In reality there are very few scenarios where the asymmetric routing is causing very bad unicast flooding.
The general fix for this is bringing your arp aging time down from 4 hours to the CAM aging time of 5 minutes (300 sec).
2. CAM table overflow attacks causing all frames in a vlan to be unicast flooded.
The obvious fix for this is to implement port-security such that it will shutdown a port that uses more than the allotted entries in the CAM table.
3. Spanning Tree TCN (especially in 802.1W and above) where a TCN BPDU causes ports CAM entries to be cleared (except for the one the TCN BPDU came in on).
The fix for this is to make sure access ports are configured as edge or with portfast (these do not generate TCN BPDUs). This ensures flapping ports dont cause unicast-flooding.