[Bridge] Re: Rapid Spanning Tree support

[Bridge] Re: Rapid Spanning Tree support

[Stephen Hemminger]

Added bridge mailing list to RSTP discussion.

On Wed, 5 Apr 2006 11:29:42 -0400
"Miller Seth-G19426" <seth.miller@motorola.com> wrote:

>  
> That's an approach we were considering as well using
> http://sourceforge.net/projects/rstplib/. Was this what you were
> planning to start with or did you want to pull the code out of the
> kernel? We're willing to work with you getting the user space app
> working and any of the infrastructure changes as well. The plan would be
> to put all this work back into the community. We're also interested in
> adding 802.1s Multiple spanning tree.
> 
> 
> -----Original Message-----
> Actually, I would like to make RSTP (and all the spanning tree
> protocols)
> a user space utility.  There are some infrastructure changes necessary
> to propagate sufficient information to do it.

I was going to leave existing STP in kernel for now, but not enable it.
For 2.6.17, I made sure that  STP packets are received so application
can receive them (via LLC).

The next part would be adding a netlink interface to bridge module
to report and modify:
	* interface added/deleted from bridge
	* interface status change (carrier up/down)
	* interface forwarding enable/disable
	* forwarding table flush by interface.

[Bridge] RE: Rapid Spanning Tree support

[Miller Seth-G19426]

Stephen,

This sounds like the right approach. I'm still not sure what you 
are proposing in terms of where the RSTP code should come from. 
would you expect we should be able to pull the code out of the 
existing bridge module?

Thanks

Seth


> -----Original Message-----
> Actually, I would like to make RSTP (and all the spanning tree
> protocols)
> a user space utility.  There are some infrastructure changes necessary
> to propagate sufficient information to do it.

I was going to leave existing STP in kernel for now, but not enable it.
For 2.6.17, I made sure that  STP packets are received so application
can receive them (via LLC).

The next part would be adding a netlink interface to bridge module
to report and modify:
	* interface added/deleted from bridge
	* interface status change (carrier up/down)
	* interface forwarding enable/disable
	* forwarding table flush by interface.