xxconfig for if_bridge

[Bruce M Simpson]

Hi,

Many of these points were covered in the thread from over a year ago which
Andrew helpfully posted the link to.

On Fri, Jun 03, 2005 at 02:41:22PM -0700, Julian Elischer wrote:
> and I still don't see why it is better to import Yet another bridge 
> module rather
> than adding it to the 2 we already have.
> You can do things with ng_bridge that you can't do with if_bridge..
> for example bridge together 3 remote sites connected by ipsec tunnels.

Don't get me wrong, I'm not knocking Netgraph -- it is a nice concept, but
it needs more work in order to offer our users the same performance as
more traditional ifnet layer code. It is also obscure to configure for many
of our users.

I think the benefits are quite concrete and speak for themselves.

1) Common code with NetBSD and OpenBSD.

 This should be obvious -- code which has been shown to be good in these
 other two BSDs will enable us to pick up fixes and improvements from those
 lines of development.

 Where Netgraph bridge implementations are concerned, it has to be pointed
 out: Netgraph is not part of NetBSD or OpenBSD, so further development of
 ng_bridge(4) does not offer this particular benefit.

2) Working firewall support through the use of the appropriate mbuf tags.

 Whilst this is something which may be *possible* with Netgraph, I have yet
 to see working code for it, which is why I'm puzzled by the persistent
 argument of 'you should do it with Netgraph!' by the Netgraph devotees.

3) New features, particularly spanning tree.

 Not only have we been behind the other BSDs in terms of feature set,
 we've also been behind Linux. Spanning Tree is one of the real wins
 from importing if_bridge(4).

4) It serves as a good example and basis of how to do Layer 2 things at
   the ifnet layer for future projects.

 Based on my reading of the code, it's cleaner than bridge(4).

 if_bridge(4) incorporates spanning tree as above -- this is a concrete
 starting point for doing things like 802.11s Mesh.

 The forwarding table for spanning tree has a clear logical separation
 from the existing ARP code.

5) It does not suffer from the same issues which bridge(4) has had.

 bridge(4) has had a number of issues. In particular I'm thinking of things
 such as disabling and reenabling hardware checksumming.

6) Performance is roughly equal and in some cases better than bridge(4).

With this in mind, bridge(4) should be deprecated sooner than later --
I would hope that 6-CURRENT gets enough test coverage that this can
happen either in time for 6-RELEASE, if not 7.

Regards,
BMS