[LinkSec] Re: [802.1] Fwd: Require Help in Resolving 802.1s issues
I recommend looking at the drafts for 802.1y or 802.1D-2003 which include the
list of known issues (including 802.1w bugs) in Annex Z. The last draft which
had this in was 802.1D draft 2, which can be found on the 802.1 website at
http://www.ieee802.org/1/files/private/d-rev-drafts/d2/802-1D-D2.pdf
Les...
Perry Zhang <pzhang_xa@yahoo.com> on 10/10/2003 11:28:35
Sent by: Perry Zhang <pzhang_xa@yahoo.com>
To: Tony Jeffree <tony@jeffree.co.uk>, stds-802-1@ieee.org, "stds-802-linksec
@ieee.org" <stds-802-linksec@ieee.org>
cc: (Les Bell/GB/3Com)
Subject: Re: [802.1] Fwd: Require Help in Resolving 802.1s issues
I wonder if there is a list as below for the
known-bugs of 802.1w.
sometimes, it's so hard to tell where the problem come
from, the standard or implementation.
so, if there IS one, please give me a copy.
Thanks.
Perry
--- Tony Jeffree <tony@jeffree.co.uk> wrote:
> 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?
>
>
__________________________________
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search
http://shopping.yahoo.com