
Rapid Spanning Tree Visio Simulation
=====================================

Requirements
------------
This software has been software has been built and tested on Visio 2002 (SR1) running under WinXP. It is also intended to run under Visio 2000 (SR1) and on Win 2000, WIN NT4 and Win98/Me.  It is your responsibility, not ours, to ensure that you are running a legally licensed copy of Visio. We do not distribute Visio.

Distribution
-------------
Releases of the simulation tool for standards contribution and study are distributed by posting a .zip file in the P802.1 documents directory and announcing this on the P802.1 email exploder.
 
Documentation
-------------

See the Rapid Spanning Tree Simulation Guide (PDF) that accompanies the standard distribution.

Version 2400 Release Notes
--------------------------

Version 2400 of the RSTP Simulation attempts to implement P802.1D/D3 June 11 AND ALSO INCLUDES the changes suggested in my (draft) sponsor ballot comments included below.

A counter for the number of times the Filtering Database is flushed on each port is included. It assumes a model where the filtering database can be flushed instantly. If, for example, the database took 10 milliseconds to flush the count would be somewhat lower since high flush count are usually associated with closely packed events.

As noted in the simulation guide the implementation is deliberately slow, rescheduling internal events with additional millisecond delays so that the progress of the state machines can be more readily seen.
-------------------------------------------------------------------
PROPOSED SPONSOR BALLOT COMMENTS BELOW

NAME: Mick Seaman
COMMENT TYPE: TR
CLAUSE: 17.20.3 allSynced
PAGE: 158
LINE:
COMMENT START:
The description of allSynced is given as:

“TRUE if and only if synced is TRUE for all Ports for the given Tree.”

Whereas in .1w allSynced was defined as:

….synced is true ..”for all Ports other than this Root Port”

A change to the definition was required to accommodate the fact that “this … Port” could be other than the Root Port, however synced is never true for the Root Port so the appropriate change was to replace “this Root Port” with “the Root Port” rather than to remove the qualification entirely.

In addition to the above it is necessary to know that synced for each Port is actually a current representation of the intended state of the port so the value of synced should be qualified just as for the other port role transitions (discrepancies here will not have shown up in most serially executed single processor software implementations).

COMMENT END:
SUGGESTED CHANGES START:

 “TRUE if and only if, for all Ports for the given Tree, selected is true and the port’s role is the same as its selectedRole and either:
a)	synced is true; or
b)	the port is the Root Port.”

SUGGESTED CHANGES END:


















NAME: Mick Seaman
COMMENT TYPE: TR
CLAUSE: 17.21.1 betterorsameinfo()
PAGE: 159
LINE:
COMMENT START:
The clause describes the procedure betterorsameinfo() using the following words:

 "Returns TRUE if the proposed replacement priority vector (either the received message priority vector or the designated priority vector) is better than or the same as (17.6) the port priority vector."

This procedure is referenced from the state machines, which in all other respects have (or are intended to have)  the property that their contents can be directly used by a C++ compiler. Clearly this does not apply to this procedure since the words "the proposed replacement vector" are not given formal expression at the point that the procedure is called. It is highly desirable that this weakness be fixed so that implementations of the state machine do not accidentally perform an incorrect comparison.

The procedure represents a relaxation of rules in the prior revision of the standard that represented an equality or "sameinfo" condition. This condition automatically assured that the check that the procedure represented could only be satisfied if the proposed replacement vector was from the same source, either received or from the bridge itself, as the current vector. The new check lacks this condition, and in consequence can result in an interruption in the flow of new information propagation through the network (verified by simulation) though not a straight forward error (a data loop).

COMMENT END:
SUGGESTED CHANGES START:
Change the procedure heading in 17.21.1 to betterorsameinfo(newInfoIs), and the two references to the procedure in the states PIM:SUPERIOR_DESIGNATED and PIM:UPDATE to betterorsameinfo(Received) and betterorsameinfo(Mine)respectively.

Change the description of the procedure to read

"Returns TRUE if either:
(a)	the procedure's parameter newInfoIs is Received and infoIs is Received and the msgPriority vector is better than or the same as (17.6) the portPriority vector; or,
(b)	the procedure's parameter newInfoIs is Mine and infoIs is Mine and the designatedPriority vector is better than or the same as (17.6) the portPriority vector.

Returns False otherwise."

SUGGESTED CHANGES END:




NAME: Mick Seaman
COMMENT TYPE: TR
CLAUSE: 17.21.7 newTcWhile()
PAGE: 159
LINE:
COMMENT START:
The current clause text is:

“Sets the value of tcWhile to twice HelloTime on point-to-point links (i.e., links where the operPointToPointMAC parameter is TRUE; see 6.4.3) where the partner bridge port is RSTP capable, and to the sum of the Max Age and Forward Delay components of rootTimes otherwise (non-RSTP capable partners or shared media).”

This wording omits changes documented as being agreed in clause Z.18.1 of the Commentary Annex present in the working group level draft D1 (due to an editorial oversight). These set TcWhile only if it is not already running. Setting of the newInfo variable should also be within the conditional test, and not in the TCM:PROPAGATING state, as setting it unconditionally can lead to many duplicate transmissions.

COMMENT END:
SUGGESTED CHANGES START:
Replace the clause text with

“If the value of tcWhile is zero and sendRstp is true, this procedure sets the value of tcWhile to HelloTime plus one second and sets newInfo true.

If the value of tcWhile is zero and sendRstp is false, this procedure sets the value of tcWhile to the sum of the Max Age and Forward Delay components of rootTimes and does not change the value of newInfo.

Otherwise the procedure takes no action.”

Remove “newInfo = true” from the TCM:PROPAGATING state (Figure 17-25).

SUGGESTED CHANGES END:

NAME: Mick Seaman
COMMENT TYPE: ER
CLAUSE: 17.21.9 recordAgreement()
PAGE: 160
LINE:
COMMENT START:
The part of the text that reads "a message priority the same as or worse than the port priority vector, and a Port Role of Root Port, Alternate Port, or Backup Port," is pure tutorial, and explains when this (the recordAgreement()) procedure is called. This is in contrast to the rest of the text in the paragraph, which actually needs to be coded by someone producing a software implementation of the standard. This mix of tutorial with normative text within a single sentence is confusing. The context within which the procedure is called is sufficiently explained elsewhere.
COMMENT END:
SUGGESTED CHANGES START:
Delete the quoted text.
SUGGESTED CHANGES END:




NAME: Mick Seaman
COMMENT TYPE: TR
CLAUSE: 17.21.9 recordAgreement()
PAGE: 160
LINE:
COMMENT START:
The clause states "If ..the agreed flag is set. Otherwise the agreed flag is cleared." The procedure described by this clause replaces conditional state machine actions in the prior revision of this standard which specify "agreed = False; proposing = False". The change to "proposing" appears to have been accidentally omitted, with the result that more BPDUs are transmitted than required (verified by simulation).
COMMENT END:
SUGGESTED CHANGES START:
Replace the quoted parts of the text with "If ..the agreed flag is set and the proposing flag is cleared. Otherwise the agreed flag is cleared."
SUGGESTED CHANGES END:

NAME: Mick Seaman
COMMENT TYPE: TR
CLAUSE: 17.21.10 recordDispute()
PAGE: 160
LINE:
COMMENT START:
The clause states "Sets the disputed variable and clears the agreed variable for the port if an RST BPDU with the learning flag set has been received.”

Experience has shown that this is open to misinterpretation with the “if” only being applied to the agreed flag.

COMMENT END:
SUGGESTED CHANGES START:
Replace  with "If an RST BPDU with the learning flag set has been received:
a)	the agreed flag is set; and
b)	the proposing flag is cleared."
SUGGESTED CHANGES END:

NAME: Mick Seaman
COMMENT TYPE: TR
CLAUSE: 17.23 Port Receive state machine Figure 17-14
PAGE: 167
LINE:
COMMENT START:
The setTcFlags() procedure is called from the receive state machine PRX:RECEIVE state. This is undesirable (a) because the flags get set even if the BPDU is to be ignored after analysis of the received MsgPriority vector and port role has been carried out (b) calling setTcFlags() on a per tree basis (even there is only one tree in .1D) will maximize commonality between .1D and the per tree aspects of .1s/.1Q. 
The flags should only be set if rcvInfo() results in the Port Information Machine executing the PIM:SUPERIOR_DESIGNATED, REPEATED_DESIGNATED, or NOT_DESIGNATED states i.e. not in the PIM:INFERIOR_DESIGNATED and OTHER states. 
COMMENT END:
SUGGESTED CHANGES START:
Remove setTcFlags() from PRX:RECEIVE and add to PIM:SUPERIOR_DESIGNATED, REPEATED_DESIGNATED, and NOT_DESIGNATED.
SUGGESTED CHANGES END:

NAME: Mick Seaman
COMMENT TYPE: TR
CLAUSE: 17.28 Figure 17-19
PAGE: 167
LINE:
COMMENT START:
The name of the state RECEIVE is clearly an accidental editorial mishap. The name should be ROLE_SELECTION, as in the previous revision of the standard.
COMMENT END:
SUGGESTED CHANGES START:
Replace the state name RECEIVE with ROLE_SELECTION.
SUGGESTED CHANGES END:

NAME: Mick Seaman
COMMENT TYPE: TR
CLAUSE: 17.29.1 Figure 17-20
PAGE: 168
LINE:
COMMENT START:

Although there is an unconditional transition (UCT) from PRT:INIT_PORT to PRT:DISABLE_PORT the latter will not execute until BEGIN is deasserted (as is made clear in clause 17.16). The order of execution of states in different machines is deliberately unspecified so it is therefore quite possible for a conformant implementation to execute PST:LEARNING and PST:FORWARDING following initialization before learn and forward get set false by PRT:DISABLE_PORT. It is highly likely that no serial single processor implementation as thought to do so yet, but the specification is not limited to such implementations.

COMMENT END:
SUGGESTED CHANGES START:
Add “forward = learn = false” to the PRT:INIT_PORT state.
SUGGESTED CHANGES END:


NAME: Mick Seaman
COMMENT TYPE: TR
CLAUSE: 17.29.1 Figure 17-20
PAGE: 168
LINE:
COMMENT START:

This revision of the standard has radically shortened the time taken for a port to become forwarding, even on shared media where the default time to transition from Discarding to Forwarding is down to 4 seconds from 30. If the worst case time for allowing prior information to time out is taken into account the total reconfiguration time for shared media is down to 10 seconds from 50 seconds (of course for shared media much shorter time in the milliseconds or tens of milliseconds are possible).

However there is a worst case remaining which is not addressed by P802.1D/D3 and could result in a data loop when a port is first enabled on shared media (plugged into an already working LAN). If the prior Designated Bridge is removed just before the new system is plugged in and there is a legacy STP Bridge on the LAN, that Bridge could take up to Max Age (20 secs default) before it is willing to accept a BPDU from any Bridge of worse priority than the recently removed Designated Bridge. The legacy STP Bridge could be a parent (in the tree) of the newly plugged in port.

Fortunately there is no need to impact the reconfiguration performance using shared media to fix this problem, just the initial value of fdWhile needs to be set to cover the time for the legacy Bridge to forget the prior Designated Bridge. Thereafter fdWhile = HelloTime can be used if RSTP (as opposed to STP) BPDUs are being transmitted.

COMMENT END:
SUGGESTED CHANGES START:
In PRT:INIT_PORT and PRT:DISABLED_PORT replace “fdWhile = forwardDelay” with “fdWhile = MaxAge” and change the transition that circulates from this state back to itself to test for fdWhile == MaxAge (instead of fdWhile = FwdDelay or fdWhile = forwardDelay).
SUGGESTED CHANGES END:


NAME: Mick Seaman
COMMENT TYPE: TR
CLAUSE: 17.29.3 Figure 17-22
PAGE: 169
LINE:
COMMENT START:

The state machines can (and in P802.1D/D3 do) detect operEdge whenever there is a need for a Designated Port to attempt a rapid transition to forwarding. This may be quite useful since a ‘bridge’ on the same LAN may disappear without any physical indication (change to portEnabled) – consider a system that includes both routing and bridging functionality with the later being enabled or disabled by management. If operEdge were to be only checked at first attachment to a LAN/link then configuration changes could cause 4 second outages once in a while for months after a bridge was really at the ‘bridging edge’ of the network.

However the current state machines do not restart edgeDelayWhile whenever proposing is newly set, with the result that false operEdges can be detected if another Bridge has not transmitted on the LAN recently. This does not result in a possibility of data loops but can be confusing and might delay communication of topology changes – it certainly complicates reasoning about other aspects of the protocol.


COMMENT END:
SUGGESTED CHANGES START:
In PRT:DESIGNATED_PRPOSE set edgeDelayWhile to MigrateTime() if operPointToPointMAC is true, and to MaxAge otherwise (the latter ensures that the initial setting of fdWhile in PRT:INIT_PORT is not defeated).
SUGGESTED CHANGES END:



