In the topology in this link (http://www.cisco.com/c/dam/en/us/support/docs/lan-switching/spanning-tree-protocol/10575-51b.gif). Imagine were using pvst (and not rapid-pvst)
I have some questions about the way uplink fast actually works with the TCN that gets generated.
Normally, when there is a topology change in the network (port goes into forwarding, or moved from learning or forwarding into blocking mode) a TCN is sent upstream to the root bridge. The root bridge sends a TCN replay with the Ack flag set. This then tells the other switches to age out their mac tables by setting the cam max_age time to a a period of the forwarding delay (15 secs by default).
Now then, if uplink fast is configured, and say switch A (in the topology I provided in the link at the top of this page) moves port p2 straight into forwarding then sends dummy multicast frames with the source mac's of the entries in it's cam table toward Switch D2. What happens in terms of TCN generation? Switch A should still send a TCN out as a muilticast that eventually hits the root bridge. The root bridge will then send the TCN with an Ack bit set as a reply, which causes all the downstream switches to age out their cam table within 15 secs (default forward delay timer). So that seems to defeat the feature in uplink fast whereby Switch A sends dummy multicast frames so that Switch D2 can update its cam table. The idea behind that feature was to ensure the forwarding path doesn't take 300 seconds to age out (and potentially black hole traffic), which it achieves - i.e. forced Switch D2 to learn the new forwarding port to reach the mac addersses hanging off Switch A. However, D2 is gonna forget all these entries now within 15 seconds & again have to re-learn them.
So ultimately my question is, am I correct in my assumptions whereby TCN really works against uplink fast? or am I missing something here?