On Fri, Mar 06, 2015 at 10:22:26AM -0800, Jean Tourrilhes wrote:
> Ken Ajiro wrote :
> >
> > To isolate the L2 domain equivalent to VLAN,
> > I think that following flow entries will be needed.
> >
> > in_port=1,vlan_id=100,actions=output:2,output:7,output:8
> > in_port=1,vlan_id=110,actions=output:2,output:7,output:8
> > in_port=1,vlan_id=120,actions=output:2,output:7,output:8
> > in_port=1,drop
> > in_port=2,vlan_id=100,...
>
> The way to avoid cross product explosion has always been to
> use multiple tables.
> Actually, Egress Tables introduced in 1.5 were explicitely
> designed to address this use case in a generic fashion, because Egress
> Tables have exactly the semantic you want. Instead of adding a table
> in the output port restricted/dedicated to only VLAN and nothing else,
> it introduce a generic OpenFlow table after the output action, so that
> not only you can do VLAN filtering, but you can also implement STP
> filtering, Reverse Path Filtering or any per-output port policies. In
> other words, it is future proof.
> In other words, please look at implementing Egress Tables in
> OVS instead of Hybrid Port VLAN. IMHO, I think Ben would be more
> likely to merge it. I think the current trend of trying to push more
> and more specialised/dedicated features in OVS is not sustainable.
That's a good point.
Another possibility is to use the "conjunctive match" feature in
(upcoming) OVS 2.4. With this feature, you can effectively construct
flows that say,
(in_port in {set_A}) and (vlan_id in {set_B}),actions=...
by adding n_A + n_B + 1 flows to the flow table, where n_A is the
number of elements in {set_A} and n_B is the number in {set_B}. But I
doubt that that feature maps well to hardware.
_______________________________________________
dev mailing list
[email protected]
http://openvswitch.org/mailman/listinfo/dev
