Re: [PATCH V2 00/12] Add basic VLAN support to bridges

[Shmulik Ladkani <shmulik.ladkani@gmail.com>]

Hi Vlad,

On Wed, 19 Dec 2012 09:13:10 -0500 Vlad Yasevich <vyasevic@redhat.com> wrote:
> > Why the "untagged vlan" is per-bridge global?
> It's not.  There is a per port untagged pointer where you can designate 
> which VLAN is untagged/native on a port.

Ok (misinterpreted the text in the cover letter).

> > 802.1q switches usually allow conifguring per-vlan, per-port
> > tagged/untagged egress policy: each vid has its port membership map and
> > an accompanying port egress-policy map.
> > This gives great flexibility defining all sorts of configurations.
> 
> Right, and that's what's provided here.
>   * Each VLAN has port membership map (net_bridge_vlan.portgroup).
>   * Each port has a list of vlans configured as well 
> (net_port_vlan.vlan_list).
>   * Each port also has a single vlan that can be untagged 
> (net_bridge_port.untagged).
>   * The bridge also has a single untagged vlan (net_bridge.untagged)
> 
> The limitation (in switches as well) is that only a single VLAN
> may be untagged on any 1 port. 

Switches usually allow you to configure each port's egress policy per
vlan, and allow you to configure multiple vlans to _egress_ untagged
on a port.

> If you have more then 1, you don't know
> which VLAN the untagged traffic belongs to.

The port's PVID uniquely determines VID to associate with the frame
during _ingress_ on that port - in the case frame arrived untagged.

This is unrelated to whether a frame having a specific VID would _egress_
tagged or untagged on that port.

> > Personally, I'd prefer a fully flexible vlan bridge allowing all sorts
> > of configurations (as available in 802.1q switches).
> >
> > What's the reason limiting such configurations?
> 
> So, what do you see that's missing?

I suspect some configurations wouldn't be possible at current design,
please let me know what do you think.

Take for example such a configuration:

 +---+---+
 |   |   |
p1  p2   p3

A bridge with 3 ports: p1 p2 p3.
(the bridge interface itself is irrelevant for this discussion)
	
This setup expects all traffic at those ports to be untagged.

I'd like p1 to be bridged to p2, but not to p3.

I'd like p3 to be bridged to p2, but not to p1.

Set the following:

p1 - PVID is 1
    member of VLANs 1(egress untagged), 2(egress untagged)

p3 - PVID is 3
    member of VLANs 3(egress untagged), 2(egress untagged)

p2 - PVID is 2
    member of VLANs 1,2,3 (all egress untagged)

Or putting it differently:

VLAN 1 ports membership: p1, p2
       egress policy:    U   U

VLAN 2 ports membership: p1, p2, p3
       egress policy:    U   U   U

VLAN 3 ports membership:     p2, p3
       egress policy:        U   U

Now, untagged traffic arriving at p1 will be assigned its PVID, which
is 1, an thus forced to egress via p2 (the only other member of VLAN 1).
Upon egress on p2, it will egress untagged.

(similarly for ingress in p3, only egress at p2 is possible, again
 untagged).

If untagged traffic arrives at p2, it will be assigned its PVID, which
is 2, and thus it may egress on either p1 or p3 (they are both members
of VLAN 2).
Actual port of egress is according to FDB match.
Again egress would be untagged.

This setup might sound exotic, but similar patterns may be used in
reality.
Although the example is synthetic and simplistic, still it demonstrates
the vast flexibility allowed by a 802.1q bridge.

The bridge constructs needed for supporting such setups are:
- per port: PVID
- per VLAN: port membership map
- per VLAN: port egress policy map

I agree, tools other than a vlan bridge may implement such setups, but
using the vlan bridge would be preferred, mainly due to the simplicity.

Regards,
Shmulik