Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

[LinkSec] 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