On Fri, 2 Dec 2016 15:32:24 +0000, Jan Scheurich wrote: > However, I would still like to make the point that EXT-382 is > designed to allow more flexibility for an OF controller to deal with > encapsulation stacks.
"More flexibility" is not a holy grail. It makes sense only when it brings some value. Which this doesn't, see below. > The following could be possible and make sense from an PTAP OF > controller perspective to flexibly deal with stacks of VLAN tags > instead of using the old "hard-wired" push/pop_vlan actions: So why don't we have also a decap action to remove only the destination MAC address? We could assign an ethertype for such partial header, no problem. It would surely allow greater flexibility, right? It makes as much sense as decap of Ethernet headers while keeping vlan tag in place - zero. Openflow can match on these fields (destination MAC address, vlan id, etc.) and can modify them. Why on Earth do you need to duplicate that with encap/decap? > This is just to illustrate the point regarding encap/decap. In > reality the controller would likely map the VLAN tags to metadata to > match on in the FIB table for tenant VRF separation. So, practical usefulness is also zero. I just don't see a point. But I see a lot of complications and problems in implementing this. The Ethernet header should be added and removed only as a whole, i.e. including vlan tags. Removing partial Ethernet header does not make sense and does not add any value. Jiri _______________________________________________ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
