Re: improvements

[Darren Reed <darrenr%netbsd.org@localhost>]

On 1/10/2013 4:59 AM, Manuel Bouyer wrote:
> 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 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