Re: improvements

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

On Tue, Oct 01, 2013 at 04:50:31AM +1000, Darren Reed wrote:
> On 30/09/2013 8:44 PM, Manuel Bouyer wrote:
> > On Mon, Sep 30, 2013 at 06:56:54AM +1000, Darren Reed wrote:
> >> On 29/09/2013 8:24 PM, Manuel Bouyer wrote:
> >>> ...
> >>> 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.

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