Supporting 9100, or even 8100 would be nice if they are easy. If we have to make a choice, I'd rank 88a8, followed by 9100, then 8100. My understanding is that 9100 was fairly popular in older networking equipments. Openflow1.1 only requires 88a8.
On Mon, Apr 14, 2014 at 8:05 AM, Thomas F Herbert <thomasfherb...@gmail.com> wrote: > Andy and Manikanta, > > I agree with Andy/ I don't think there is a necessity for any design changes > in OVS for qinq at least for Open Flow 1.1. I am working on > debugging/testing the patch now. > > Right now I am working on debugging my double tagging patch as specified in > 802.1ad with an outer TPID of 0x88a8 and this is what I am testing against. > There are some legacy switches in use that support an older form of qinq > with outer tags of 0x8100 or 0x9100. Please let me know your thoughts on > this. My suggestion would be to allow any tpid the controller sets in the > flow to work. > > I am not sure about more than 2 levels of stacked tags. I haven't seen that > and I don't think it is specified but I would like to hear your thoughts. > > --Tom > > > On 4/14/2014 10:11 AM, Andy Zhou wrote: >> >> 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? >> >>> 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. >> >>> 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 >>> > _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
