Hi, Thanks Tom for the patch. The patch is clear and concise. We are looking forward for the testing results of the working patch.
Currently, if a VLAN packet is received by the openvswitch, where the input switch port is having vlan_mode as: a. trunk, the packet is forwarded to the respective destination MAC address. b. access, the packet is dropped. As mentioned by manikanta, how about having a new vlan mode for the switch port to distinguish ports with/without QinQ support. Any other ideas ? If this design of having new vlan mode looks good, we are also interested in implementing stacked VLAN support (OF1.2+ spec) with this design. -- Avinash On 4/15/14, Manikanta Srinivas <srinivas...@outlook.com> wrote: > Thanks for the reply. Please find my responses inline. > >> Date: Mon, 14 Apr 2014 07:11:11 -0700 >> Subject: Re: [ovs-dev] [PATCH v3] Add Support for 802.1qad (qinq) Allows >> TPID of 0x88a8 >> From: az...@nicira.com >> To: srinivas...@outlook.com >> CC: thomasfherb...@gmail.com; dev@openvswitch.org >> >> On Mon, Apr 14, 2014 at 4:27 AM, Manikanta Srinivas >> <srinivas...@outlook.com> wrote: >> > Hi, >> > >> > Thanks for your efforts. We are interested in QinQ implementation of >> > openvswitch. After going through the patch, we are left with following >> > queries. >> > >> > 1. We think there should be a separate mode to support qinq tunnel. This >> > can >> > be achieved by implementing a new configuration parameter in ovsdb. Do >> > you >> > have any plans to implement this approach or any other ideas ? >> >> What kind of new configuration do you have in mind? > > My understanding on QinQ: > > When a VLAN tag packet arrives the switch port, then if the port is: > > a. normal access: the packet is dropped. (as there is no qinq support) > b. qinq access: new outer VLAN tag is appended over the C-Vlan tag. > c. trunk (having qinq support): the packet is forwarded based on the > destination MAC address. > > If the above mentioned cases are valid, then we might need a new > configuration parameter to support qinq ? > >> >> > >> > 2. The structure "sw_flow_key" should be extended to represent the >> > information of outer VLAN (service VLAN) in flow key. Similar change is >> > also >> > required in flow structure (lib/flow.h) used in user space. >> >> We don't strictly need those changes for Thomas' patch. open-flow1.0 >> and 1.1 support >> exactly one vlan tag. Open flow 1.1 requires 802.1ad tag to be >> recognized. >> Thomas' patch is a great step forward to support Openflow 1.1. >> >> Openflow 1.2+ removed packet parsing requirements. So we could support >> the model you proposed. >> However, this would limit us to support fix number of VLAN tags, for >> example, double tagging as you have suggested. >> This is not a bad idea and should cover most of the use cases out >> there. On the other hand, Openflow >> spec does not rule out supporing multiple vlan tags. Since we are >> going to support MLPS label stacking, we could also support >> vlan stacking without much added efforts. >> > > Thanks. If the specification says so, there is no issue. Also the mentioned > approach would limit > for only double VLAN tagging and might not support for multiple tags. > May be I can have better understanding after seeing the testing results. > >> > >> > Please correct our understanding if we went wrong somewhere. >> >> This is good time to voice your opinion and use cases. We'd like to >> flush out the design for openflow 1.2+ support. >> Thank you for your interest and participation. >> >> > >> > Thanks and Regards, >> > Manikanta Srinivas >> > > -- AVINASH _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
