improvements

[Darren Reed]

In reference to:
http://www.netbsd.org/~msaitoh/saw1.pdf

My though about swconfig is that it's in some way redundant with
brconfig. As I see it, both allow configuring a subsystem which allows
interconnecting ethernet interfaces; one of them being implemented in
software. I see that hardware switches allows much more than bridge(4)
actually can do, but bridge(4) could be extended. Some of these
features (such as 802.1q vlans) would be usefull for virtualisation.

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.)

Darren


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Thor Lancelot Simon]

Post by Darren Reed
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.

The tricky part would be expressing in all cases how the system's
physical network interfaces are connected to the controlled bridge/switch,
if at all. For software, sure, that's easy. For hardware, not so much.

Also, there are hybrids, like hardware switches that kick control frames
(such as STP) out a particular port, or even out a non-Ethernet interface.
Those would need the STP implementation from bridge(4) but not other parts
of it; similarly, they might need the LACP implementation from agr(4) but
not the actual frame distribution/collection. In fact, it's likely that
one would often need half of agr(4) to support such a switch chipset's
hardware link aggregation, while needing another instance of *all* of it
to actually get packets moving between the switch and the host...

This can get pretty confusing pretty quickly. I've carboned one of my
former coworkers who maintains the L2 switch code where I used to work;
maybe he'll comment if he thinks it's appropriate.

Thor

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Manuel Bouyer]

Post by David Young

Post by Thor Lancelot Simon

Post by Darren Reed
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 ?

[Darren Reed]

Post by Manuel Bouyer
...
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 ?

Simple.

Create multiple vlan(4) interfaces per port and have each vlan(4)
interface be a member of a different bridge(4) domain.

Darren


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Manuel Bouyer]

Post by Darren Reed

Post by Manuel Bouyer
...
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 ?

Simple.
Create multiple vlan(4) interfaces per port and have each vlan(4)
interface be a member of a different bridge(4) domain.

I'm not sure I like this. This is the opposite of how you manage a
real switch (hp, cisco, etc ...). On these device, you have a single view
of the switching fabric, with vlan tag information when pertinent.

[Mouse]

Post by Darren Reed
Create multiple vlan(4) interfaces per port and have each vlan(4)
interface be a member of a different bridge(4) domain.

I'm not sure I like this. This is the opposite of how you manage a
real switch (hp, cisco, etc ...). On these device, you have a single
view of the switching fabric, with vlan tag information when
pertinent.

So they're different; that doesn't make either one wrong.

On a "real switch", the things that on NetBSD are bridge interfaces are
implicit; they have no visibility in the interface - there is
implicitly one per vlan, so there is nothing to configure except which
vlan(s) a each non-trunk port belongs to, and which tags are acceptable
on each trunk port. That NetBSD configures this information via the
vlan pseudo-devices rather than the underlying interface devices
reflects its more general-purpose nature.

I actually prefer the NetBSD way...though I do wish vlan(4) had a way
to configure a vlan interface to get/generate untagged packets or, for
input, packets with a tag not otherwise claimed.

/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTML ***@rodents-montreal.org
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Darren Reed]

Post by Manuel Bouyer

Post by Darren Reed

Post by Manuel Bouyer
...
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 ?

Simple.
Create multiple vlan(4) interfaces per port and have each vlan(4)
interface be a member of a different bridge(4) domain.

I'm not sure I like this. This is the opposite of how you manage a
real switch (hp, cisco, etc ...). On these device, you have a single view
of the switching fabric, with vlan tag information when pertinent.

Remember that what you're comparing here is the design of the underlying
system that you never see with a Cisco/HP switch. All that you see from
them is what the management interface presents.

Darren



--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Manuel Bouyer]

Post by Darren Reed

Post by Manuel Bouyer

Post by Darren Reed

Post by Manuel Bouyer
...
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 ?

Simple.
Create multiple vlan(4) interfaces per port and have each vlan(4)
interface be a member of a different bridge(4) domain.

I'm not sure I like this. This is the opposite of how you manage a
real switch (hp, cisco, etc ...). On these device, you have a single view
of the switching fabric, with vlan tag information when pertinent.

Remember that what you're comparing here is the design of the underlying
system that you never see with a Cisco/HP switch. All that you see from
them is what the management interface presents.

that's true, but I'd prefer to keep our management interface close to that,
instead of the opposite. Because that's what peoples are used to.

And BTW, I have some knowledle in electronics, and if I had
to design such a device, I would go with a single switching fabric
understanding vlan tags instead of multiple ones with dispatch based
on tag from the input port, because multiplexing is always good for
ressource managements. Actually (from reading the docs) I suspect
larger switches may have multiple switching fabrics (a few), but the dispatch
is based on QoS classification instead of vlan tags.

[Darren Reed]

Post by Manuel Bouyer

Post by Darren Reed

Post by Manuel Bouyer

Post by Darren Reed

Post by Manuel Bouyer
...
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 ?

Simple.
Create multiple vlan(4) interfaces per port and have each vlan(4)
interface be a member of a different bridge(4) domain.

I'm not sure I like this. This is the opposite of how you manage a
real switch (hp, cisco, etc ...). On these device, you have a single view
of the switching fabric, with vlan tag information when pertinent.

Remember that what you're comparing here is the design of the underlying
system that you never see with a Cisco/HP switch. All that you see from
them is what the management interface presents.

that's true, but I'd prefer to keep our management interface close to that,
instead of the opposite. Because that's what peoples are used to.
And BTW, I have some knowledge in electronics, and if I had
to design such a device, I would go with a single switching fabric
understanding vlan tags instead of multiple ones with dispatch based
on tag from the input port, because multiplexing is always good for
resource managements. Actually (from reading the docs) I suspect
larger switches may have multiple switching fabrics (a few), but the dispatch
is based on QoS classification instead of vlan tags.

Ok, I see what you're saying is missing: the ability to manage an
ACL for each port that specifies which VLANs are allowed and for
the bridge to take the VLAN tag into consideration when forwarding
packets. Right?

Darren


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[David Young]

Post by Thor Lancelot Simon

Post by Darren Reed
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.

Dave