[802.1] Fwd: Require Help in Resolving 802.1s issues
Any views?
Regards,
Tony
>Envelope-to: tony@jeffree.co.uk
>Reply-To: <lakshman@avnisoft.com>
>From: "Lakshmanan prithiviraj" <lakshman@avnisoft.com>
>To: <tony@jeffree.co.uk>
>Cc: <sameer@avnisoft.com>,
> <chrisp@avnisoft.com>,
> <lakshman@avnisoft.com>
>Subject: Require Help in Resolving 802.1s issues
>Date: Thu, 9 Oct 2003 18:43:13 -0700
>X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0)
>Importance: Normal
>
>Tony:
>
>We are finishing the software development of the 802.1s MSTP, we have some
>specific issues with the standard,
>We would like to know, whom to address these and where to find information
>on errata on 802.1s. We have attached the issues for your reference. We
>greatly appreciate any help in resolving these issues.
>
>Thank you very much,
>
>Lakshmanan
>
>Lakshmanan Prithiviraj
>Technical Lead, Networking & Protocols Grp.
>Avnisoft Corporation,
>Sunnyvale, CA 94085
>Ph: 408-655-8624
>
>
>
>
>
>
>
Regards,
Tony
According to 802.1s 2002,
1. clearAllRcvdMsgs (13.26.3) definition seems to specify that
rcvdMsg for the CIST and all MSTIs need to be cleared for all the
ports.
Should'nt this be done just for the port in question and not all the
ports?
2. An issue related to the implementation of updtRcvdInfoWhileCist
(13.26.23) and updtRcvdInfoWhileMsti (13.26.24) is that the
modification of port priority vector in the routines would result in
incorrectly identifying a new message as SuperiorDesignatedInfo in
rcvInfoCist (13.26.7) and rcvInfoMsti (13.26.8) routines since the
port times are now different from the message times.
Any updates on this?
3. Incorrect/incomplete definition for Superior message under 13.10;
One of the checks for SuperiorMessage requires that the message
priority vector contain the same designated bridge and port.
Should'nt this also include the clause that the port and message
priority vectors or times are different?
4. A new bug has been introduced in IEEE 802.1s 2002 which did not
exist in draft 13. The Port Information state machine(13.31) DISABLED
state does not contain the reselect assertion which is required for a
role computation after a port on a bridge is disabled.
Any updates on this?
5. Incomplete info in rcvInfoCist(13.26.7)/rcvInfoMsti(13.26.8);
These routines do not specify to check the role encoded in the BPDU
for RST/MST BPDUs nor do they specify the check for STP BPDUs as done
in the RSTP standard.
Any updates on this?
6. Assuming that we need to follow the iteration order of the state
machine as listed in IEEE 802.1s 2002, the Role Selection FSM (13.32)
computes the role in the variable "selectedRole". The Transmit FSM
(13.30) which is iterated subsequently uses the old role value from
the "role" variable to set the flag. The Role Transition FSM which is
iterated after the Transmit FSM updates the variable "role" with
"selectedRole" which is already too late for the previous BPDU sent
out. This will result in the transmission of a BPDU with a priority
that is inconsistent with the role.
NOTE:- If the assumption of the iteration order based on the FSM
listing is incorrect this cannot be held as a bug but may open other
potential issues if FSM iteration re-ordering is legal.
Any updates on this?
7. The txMstp definition specifies the usage of the "agreed"
variable for setting the AGREE flag of the BPDU but the "agree"
variable definition specifies that it should beused for this purpose.
Should the "agree" variable be used for setting the flag?