Re: 802.1D/Linux STP issue
At 01:15 15/09/2006, Stephen Hemminger wrote: On Thu, 14 Sep 2006 17:51:50 +0100 Tony Jeffree [EMAIL PROTECTED] wrote: Steve/Brian - You've probably seen Mick Seaman's comments on this by now - as he points out in his email, tinkering with existing STP implementations is not likely to be a rewarding exercise and I would encourage you not to go there. I would suggest that it would be a much more valuable exercise for the Linux community to replace the existing STP support with an implementation of RSTP. Regards, Tony Work is already in progress to do RSTP (by several different people), but the effort is going slowly. Steve - In that case, I would strongly suggest that you channel any additional available effort in that direction, rather than in the direction of tinkering with STP. Regards, Tony - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 802.1D/Linux STP issue
Steve/Brian - You've probably seen Mick Seaman's comments on this by now - as he points out in his email, tinkering with existing STP implementations is not likely to be a rewarding exercise and I would encourage you not to go there. I would suggest that it would be a much more valuable exercise for the Linux community to replace the existing STP support with an implementation of RSTP. Regards, Tony At 02:06 14/09/2006, Stephen Hemminger wrote: On Wed, 13 Sep 2006 15:58:49 -0700 Brian Braunstein [EMAIL PROTECTED] wrote: hi stephen and tony, i have been in contact with both of you and i figured it would make sense to get you to in contact on this issue, so here's the story: stephen is the maintainer of the linux spanning tree bridging code, an implementation of 802.1D-1998 that has very wide spread use. tony is the chair of the IEEE802.1 working group. i am trying to get my patch submitted in the linux kernel to fix a bug in the way STP behaves. stephen and i discovered that the flaw is actually in the IEEE802.1D-1998 spec, and that the linux implementation was merely following this. i contacted tony to try to see if we can get an update to the 802.1D-1998 spec, as this is what is implemented in the linux kernel, but tony said that the 1998 standard is obsolete, will not be updated, and that the 2004 RSTP spec should be used. so here's a review of what i've come across: first lets start with the bug in the 802.1D-1998 spec 1998 - 8.6.2.2 Record Configuration Information - Use you will notice that if the path cost ever goes up and everything else is held constant, the BPDU will be dropped and the network not react to the change, and the dropping of the BPDUs will make it seem like the link is down. now lets look at the equivalent section in the 8021.D-2004 spec: 2004 - 17.6 Priority vector calculations as you can see here, this bug has been fixed, because the last condition takes care of the problem, if the config message is received from the same designated bridge and designated port, then the config message is processed. so path cost increases will be recorded and reacted to. the issue is whether or not the linux kernel should go with the 1998 or 2004 spec. i would assume that the goal is to make the linux implmentation a functional implementation of the original STP, not a complete rewrite to conform to all of RSTP, so lets look at what the new standard says for normal legacy STP, to see if the bug is fixed there as well: 2004 - 17.4 STP compatibility this section seems to say that an RSTP bridge will revert to STP as defined in section 8. so then we go to section 8... 2004 - 8 Spanning tree algorithm protocol this one then refers to 802.1D-1998 for the STP spec, but also says that it is obsolete and RSTP should be used so this is a bit confusing. section 17.4 says use STP to interoperate with legacy bridges, then section 8 either says use the 1998 spec, or don't use STP at all, but if bugs in the 1998 spec cannot be correct, what are we to do with the linux code? i can write the patch to implement the new algorithm from 2004-17.6 to replace the algorithm from 1998-8.6.2.2. thanks for you help guys, hopefully we can get this bug fixed up soon, you both have been great about timely responses and it is much appreciated. Brian Braunstein 858.245.0434 I have no problem fixing the code to be spec noncompliant, there are several case where we implement the right thing rather than the standard way. I just want to make sure any such changes don't have unintended consequences. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 802.1D/Linux STP issue
On Thu, Sep 14, 2006 at 05:51:50PM +0100, Tony Jeffree wrote: Steve/Brian - You've probably seen Mick Seaman's comments on this by now - as he points out in his email, tinkering with existing STP implementations is not likely to be a rewarding exercise and I would encourage you not to go there. I would suggest that it would be a much more valuable exercise for the Linux community to replace the existing STP support with an implementation of RSTP. While we are at it can we rip it out of the kernel and develop a user-space daemon that does it instead? Setting the spanning-tree state of a port could be done with a simple ioctl (well not too simple because it would be good to support multiple STP instances so someone could code up 802.1w support and the kernel interface would already be there). Thoughts? - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 802.1D/Linux STP issue
On Thu, 14 Sep 2006 17:51:50 +0100 Tony Jeffree [EMAIL PROTECTED] wrote: Steve/Brian - You've probably seen Mick Seaman's comments on this by now - as he points out in his email, tinkering with existing STP implementations is not likely to be a rewarding exercise and I would encourage you not to go there. I would suggest that it would be a much more valuable exercise for the Linux community to replace the existing STP support with an implementation of RSTP. Regards, Tony Work is already in progress to do RSTP (by several different people), but the effort is going slowly. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 802.1D/Linux STP issue
On Wed, 13 Sep 2006 15:58:49 -0700 Brian Braunstein [EMAIL PROTECTED] wrote: hi stephen and tony, i have been in contact with both of you and i figured it would make sense to get you to in contact on this issue, so here's the story: stephen is the maintainer of the linux spanning tree bridging code, an implementation of 802.1D-1998 that has very wide spread use. tony is the chair of the IEEE802.1 working group. i am trying to get my patch submitted in the linux kernel to fix a bug in the way STP behaves. stephen and i discovered that the flaw is actually in the IEEE802.1D-1998 spec, and that the linux implementation was merely following this. i contacted tony to try to see if we can get an update to the 802.1D-1998 spec, as this is what is implemented in the linux kernel, but tony said that the 1998 standard is obsolete, will not be updated, and that the 2004 RSTP spec should be used. so here's a review of what i've come across: first lets start with the bug in the 802.1D-1998 spec 1998 - 8.6.2.2 Record Configuration Information - Use you will notice that if the path cost ever goes up and everything else is held constant, the BPDU will be dropped and the network not react to the change, and the dropping of the BPDUs will make it seem like the link is down. now lets look at the equivalent section in the 8021.D-2004 spec: 2004 - 17.6 Priority vector calculations as you can see here, this bug has been fixed, because the last condition takes care of the problem, if the config message is received from the same designated bridge and designated port, then the config message is processed. so path cost increases will be recorded and reacted to. the issue is whether or not the linux kernel should go with the 1998 or 2004 spec. i would assume that the goal is to make the linux implmentation a functional implementation of the original STP, not a complete rewrite to conform to all of RSTP, so lets look at what the new standard says for normal legacy STP, to see if the bug is fixed there as well: 2004 - 17.4 STP compatibility this section seems to say that an RSTP bridge will revert to STP as defined in section 8. so then we go to section 8... 2004 - 8 Spanning tree algorithm protocol this one then refers to 802.1D-1998 for the STP spec, but also says that it is obsolete and RSTP should be used so this is a bit confusing. section 17.4 says use STP to interoperate with legacy bridges, then section 8 either says use the 1998 spec, or don't use STP at all, but if bugs in the 1998 spec cannot be correct, what are we to do with the linux code? i can write the patch to implement the new algorithm from 2004-17.6 to replace the algorithm from 1998-8.6.2.2. thanks for you help guys, hopefully we can get this bug fixed up soon, you both have been great about timely responses and it is much appreciated. Brian Braunstein 858.245.0434 I have no problem fixing the code to be spec noncompliant, there are several case where we implement the right thing rather than the standard way. I just want to make sure any such changes don't have unintended consequences. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
