Re: improvements

[Manuel Bouyer <bouyer%antioche.eu.org@localhost>]

On Sat, Sep 28, 2013 at 08:01:38PM -0500, David Young wrote:
> On Sat, Sep 28, 2013 at 07:02:30PM -0400, Thor Lancelot Simon wrote:
> > On Sun, Sep 29, 2013 at 08:32:01AM +1000, Darren Reed wrote:
> > > 
> > > Agreed, supporting VLANs with bridge(4) would be very useful.
> > > 
> > > From a certain perspectice, swconfig(8) is nothing more than the means
> > > throughwhich the hardware is programmed.
> > > 
> > > How does brconfig need to change in order for swconfig to not be required?
> > > 
> > > Or are further changes required, such as the device model where we have
> > > a"switch" that attaches to mvls0 and a "switch" that attaches to some
> > > softwarebridge?(Both switches would be managed using the same commands.)
> > 
> > That sounds right to me.  brconfig (which would become a bit of a misnomer)
> > should control an arbitrary L2 backend, which might be implemented by a
> > driver for a hardware bridge (or switch) or might be implemented by a
> > driver that itself implements a software bridge/switch.  This would entail
> > splitting the current bridge(4) driver in half.
> 
> I find it useful to think of layer-2 forwarding domains (commonly
> they're called VLANs, but VLAN also is taken to mean a kind of
> encapsulation, so I call it a "forwarding domain" to be clear),
> each domain with one or more ports belonging to it, and "tagged" or
> "untagged" being a property of the port's domain membership.
> 
> I've described something like this before,
> <http://mail-index.netbsd.org/tech-net/2011/05/11/msg002614.html>.
> Others have given this question a much more thoroughgoing treatment than
> I have.
> 
> I think that the configuration as seen and modified by the operator
> should reflect the logical network topology, not the hardware topology.
> So, while I think the kernel should try its best to optimize for the
> cases where two forwarding domain member ports attach directly to the
> same switch matrix, I don't think that you need to burden the operator
> with the switching topology.  I figure an operator who is interested in
> such details can derive them from their dmesg, besides.

So, if I get it right, you want one bridge(4) per forwarding domain,
not one bridge that handle several forwarding domain.
How would one port belonging to several forwarding
domains (via 802.1q encap for example) be represented ?

-- 
Manuel Bouyer <bouyer%antioche.eu.org@localhost>
     NetBSD: 26 ans d'experience feront toujours la difference
--