Hi Chris,

As to the root bridge election, you are basically correct. Whenever a switch supporting STP is turned on, it considers itself a root switch and so it declares its own Bridge ID (BID) as the Root BID in the BPDUs it sends out. As soon as it receives a BPDU that contains a lower Root BID, it immediately ceases to consider itself a root switch and continues to announce the lower Root BID in its BPDUs. And if later a new BPDU arrives with even lower Root BID, that one will replace the currently stored Root BID.

You have asked when does this process arrive at a conclusion. The answer is that it never does. With each received BPDU, a switch reevaluates all affected STP parameters: whether the Root BID has changed, whether the root port should change, whether the port receiving the BPDU shall remain in its present role/state. In a stable network, all switches will arrive at an apparent STP conclusion after a few iterations of BPDU sending/receiving, however, their evaluation is continuous and never ends.

Your remark about the Root Guard feature is, I believe, not important at this point. The fact is that the Root Guard is configured on a port basis and kicks in every time that port receives a BPDU whose Root BID is even lower than the Root BID of the currently known root switch. There is no waiting for topology to stabilize.

Regarding your questions about RSTP: If a RSTP switch is connected to a 802.1D STP switch, the RSTP will fall back to STP operation on that port. No proposal/agreement process will be attempted. Regarding the proposal/agreement mechanism, it goes as follows: a port sends proposals if and only if it is the designated role and discarding or learning state (note that this requires that the port is superior to its counterpart on the other end of the link). If the other switch determines that the port should go into forwarding state (note that this means that the port will be a new root port), it first puts all its existing non-edge ports into discarding state (the sync) and then signals it via an agreement to the upstream switch. Both switches can then immediately put the ports into forwarding state, and the link has thus rapidly became forwarding. Notice now that as a result of the sync operation, some of the designated ports on the second switch may have been put into discarding state while retaining their designated role. Because a port in designated role and discarding or learning state sends proposals, the proposal/agreement mechanism has effectively now moved "below" the second switch.

If there are three links between two RSTP switches then the root switch (or the switch that is closer to root) will, at the beginning, obviously have its ports in designated role and discarding state, and so it will send proposals on those ports. The second switch will receive three BPDUs with the proposal bit set on its three ports. One of these ports will be elected as a root port, the remaining ports will be put into Alternate Discarding role/state (the Alternate role is a result of simple comparing all received BPDUs to each other, not a direct result of proposal/agreement operation). Upon receiving a proposal on the root port (which is still discarding), the second switch will try to block all non-edge designated ports. As there are none, the work is basically finished, and the switch replies with agreement on its root ports towards the root switch, and the link becomes forwarding. The Alternate Discarding ports have been discarding from the start, and because they are not supposed to transition into forwarding state, they will ignore all proposals and won't respond at all. The root switch will therefore simply slowly proceed from Discarding to Learning to Forwarding states on its remaining two ports towards the second switch.

This is a nice article on Cisco website about the RSTP operation. Give it a look, it was very helpful for me.

Best regards,

Peter