http://people.freebsd.org/~julian/layer2b.pdf
http://www.freebsd.org/~julian/layer2-current.pdf

Julian Elischer's comment:

I'm looking at what we can do to simplify this..
it's a mess.. Personally (I am biased of course) we could have
imlemented almost everything
outside of basic processing as netgraph modules.

firewall, divert, bridging, vlans, CARP, flow control.
these could have all been implemented as graph nodes..
well, too late for that.

There are problems for example I'd rather that the if_bridge code didn't
call
the driver queue directly on output but passed it to the driver by
calling ether_output_frame()
and I'm not sure that the ipfw hook on output shouldn't be in
ether_output() instead
of in ether_output_frame().

I do think the output hook of netgraph should be above the bridging hook.
If you are using netgraph you probably will use netgraph bridging as
well but
if you are using bridging that doesn't mean you don't want to do
something with netgraph..

It's a bit of a problem actually. The order of calling these things
almost wants to be adjustable because
different people seem to want to call them in different orders.