[Rstplib-users] "Slow" reconfiguration in 802.1w when Bridge Priority is changed by management

[<al...@nb...>]

It looks like the reconfiguration of the RSTP domain works
too slow when the Bridge priority is changed by management.

Consider the simplest case: two Bridges are connected with one
connection.

Now on the Bridge, that is not currently RootBridge, let us
decrease the Priority so, that it becomes RootBridge.

I see, that the domain becomes stable only after 4 seconds;
the previous designated port becomes a Backup, after that - Root.

Here is a trace (sorry):

16:47:45 B8322 > get-st-pcfg
 BridgeId: 8000-008220000001  RootId: 8000-008120000001
     p01 8001 Fwd  8000-008120000001 8000-008120000001 8001 R
 E   p02 8002 Dis  8000-008120000001 8000-008220000001 8002
 E   p03 8003 Dis  8000-008120000001 8000-008220000001 8003
 E   p04 8004 Dis  8000-008120000001 8000-008220000001 8004
16:48:06 B8322 > set-br-prio 0x4000
Changed rstp bridge priority
16:48:27 B8322 >
16:48:27:brige B8322 became root - bpdu
16:48:27:rec(B8322-p01) => Backup
16:48:27:roletrns(B8322-p01): ROOT_PORT=>BLOCK_PORT
16:48:27:topoch  (B8322-p01): TCACTIVE=>INIT
16:48:27:topoch  (B8322-p01): INIT=>INACTIVE
16:48:27:sttrans (B8322-p01): FORWARDING=>DISCARDING
16:48:27:roletrns(B8322-p01): BLOCK_PORT=>BLOCKED_PORT
16:48:27:roletrns(B8322-p01): BLOCKED_PORT=>BACKUP_PORT
16:48:27:roletrns(B8322-p01): BACKUP_PORT=>BLOCKED_PORT
16:48:28:roletrns(B8322-p01): BLOCKED_PORT=>BACKUP_PORT
16:48:28:roletrns(B8322-p01): BACKUP_PORT=>BLOCKED_PORT
16:48:29:roletrns(B8322-p01): BLOCKED_PORT=>BACKUP_PORT
16:48:29:roletrns(B8322-p01): BACKUP_PORT=>BLOCKED_PORT
16:48:30:roletrns(B8322-p01): BLOCKED_PORT=>BACKUP_PORT
16:48:30:roletrns(B8322-p01): BACKUP_PORT=>BLOCKED_PORT
16:48:31:roletrns(B8322-p01): BLOCKED_PORT=>BACKUP_PORT
16:48:31:roletrns(B8322-p01): BACKUP_PORT=>BLOCKED_PORT
16:48:31:Age(B8322-p01) => Designated
16:48:31:roletrns(B8322-p01): BLOCKED_PORT=>DESIGNATED_PORT
16:48:31:roletrns(B8322-p01): DESIGNATED_PORT=>DESIGNATED_PROPOSE
16:48:31:roletrns(B8322-p01): DESIGNATED_PROPOSE=>DESIGNATED_PORT
16:48:31:roletrns(B8322-p01): DESIGNATED_PORT=>DESIGNATED_SYNCED
16:48:31:roletrns(B8322-p01): DESIGNATED_SYNCED=>DESIGNATED_PORT
16:48:31:topoch  (B8322-p01): INACTIVE=>TCACTIVE
16:48:31:(B8322-p01) rx AGREEMENT flag !
16:48:31:roletrns(B8322-p01): DESIGNATED_PORT=>DESIGNATED_LEARN
16:48:31:roletrns(B8322-p01): DESIGNATED_LEARN=>DESIGNATED_PORT
16:48:31:roletrns(B8322-p01): DESIGNATED_PORT=>DESIGNATED_FORWARD
16:48:31:roletrns(B8322-p01): DESIGNATED_FORWARD=>DESIGNATED_PORT
16:48:31:sttrans (B8322-p01): DISCARDING=>LEARNING
16:48:31:sttrans (B8322-p01): LEARNING=>FORWARDING
16:48:31:topoch  (B8322-p01): TCACTIVE=>DETECTED
16:48:31:clearFDB (p01, B8322, other ports, 'DETECTED')
16:48:31:topoch  (B8322-p01): DETECTED=>TCACTIVE

When these 3 Bridges are connected "as a triangle", the problem is harder.

I am working 2 days to analyze it, but may be you can help me ?

The questions are:
Is this a bug in my implementation, or flow in the algorithm, or
appropriative  behavior ?
Do another implementations have the same problem ?

Best regards, Alex