Hello John,
Let's go over the individual statements.
it will immediately blocks its non-edge designated ports as long as their p2p(full duplex).
It will indeed block its non-edge ports but not because of point-to-point link nature but merely because the Designated Discarding role/state is the default, initial role/state for a new port on which RSTP has just been enabled. The same would be also valid for Shared link types.
Then this switch will send out BPDUs with the Proposal bit set. The Proposal BPDU will include cost information and BID.
Correct. Note that the Proposal is just a BPDU with a particular bit set in the Flags field but otherwise it's just an ordinary BPDU. The Proposal will be sent because the port is in Designated Discarding state, and the Proposal is sent on Designated Discarding and Designated Learning ports - however, they must be on p2p type links. Proposals are not sent on shared link types.
Through your typical RP/DP/BLK election process the other two switches will send na Agreement back
No, this is generally an incorrect assumption. A Proposal absolutely does not need to be be replied to by an Agreement - it may very well go unnoticed. If a switch sends an Agreement from one its ports then it declares that this port is its new root port, that the link may immediately become forwarding, and that all its other non-edge Designated ports have been moved to Discarding state (the Sync operation). But you have just plugged a switch in the middle of a network, and generally, it is not clear at all if this switch provides a better path towards the root than what the remaining switches already have.
To be perfectly correct, while your new switch indeed starts sending Proposals, the surrounding switches will see that these Proposals are inferior to BPDUs they originate themselves, because this new switch is not a root switch (although by default, it declares itself as a root switch). They will therefore not be influenced by the first BPDUs produced by this new switch, and they will simply send it their own BPDUs - with Proposal bit set, as the connection of the new switch has caused their previously deactivated ports become active, and hence Designated/Discarding (and therefore eligible to send Proposals).
The new switch will, upon receiving these BPDUs, note who the real root switch is, and eventually elect its own root port. Upon receiving one of the Proposals on this root port, it will put all its non-edge Designated ports into Discarding state (they are there already, as this all happens in a few seconds at most) and confirm to the upstream switch that this link is ready to be put into forwarding state by sending an Agreement. Both switches will then put the port into Forwarding state - the upstream switch will keep the port role as Designated, this new switch will declare it as the Root port.
Subsequently, all following BPDUs produced by this new switch will carry the new correct root switch ID and the appropriate root path cost. The remaining Designated Discarding ports will continue sending Proposals containing these new data. If the surrounding switches decide that this new switch provides a better path towards the root than they already have, they will Sync their non-edge ports and send an Agreement to make the link immediately forwarding.
Because the Sync operation on surrounding switches results in non-edge Designated ports become Discarding, they will start sending Proposals themselves, and the entire logic repeats further on those ports, one step further from the new switch. This is how the Proposal/Agreement wave propagates through the network. However, if this wave propagates up to a link on which there is no root port going to be elected, the Proposals will not be replied to by Agreements, and the wave will be dissipated here, and the entire process of handling the new switch will therefore be gradually finished.
Does this make sense?
Best regards,
Peter
