> > The alternative to having both bridge property "legacy-l3-tunnel" and > > a port property "layer3" would be to go for a single port property > > "tunnel-mode" with three values "layer2" (default), "layer3" and > > "versatile". "layer2" tunnel ports would only send and receive > > Ethernet packets as is. "layer3" tunnel ports would send and receive > > L3 packets with implicit conversion from/to Ethernet in the > > pipeline. Finally, "versatile" tunnel ports would send receive any > > type of supported packet as is without implicit conversion. In future > > versions of OVS the default could be changed to "versatile". > > > > > > We think that this approach would also fulfill requirements 1, 2 and > > 3. Our feeling is that this approach would also be somewhat easier to > > explain to users. It would not be backward compatible to the just > > introduced Boolean "layer3" flag, but that has not been released yet, > > so perhaps it would be ok. > > This is not so different in spirit from Jean's proposal, I believe. > > Overall, the important factors here seem to be: > > * Backward compatibility, at least for some number of releases, in the > following areas: > > (a) LISP tunnels should remain supported in their existing form, > which treats them as Ethernet. > > (b) Other tunnels that can encapsulate various inner protocols, > should by default only send and receive only Ethernet. > > * With an appropriate controller, any kind of encapsulated protocol > should be supported over a tunnel. Full support may be possible > only with OpenFlow 1.5, but we also hope for some provisions for at > least limited support with earlier versions of OpenFlow (perhaps > using Open vSwitch extensions if valuable and necessary). > > I propose: > > * options:packet-type=legacy requests legacy behavior on a tunnel, > that is, requests behavior (a) or (b) depending on the particular > kind of tunnel. > > * options:packet-type=ptap requests versatile behavior using the > packet_type feature on a tunnel. > > For now, the default for all types of tunnels would be "legacy", but > with proper forewarning to our users we could possibly change the > default to "ptap" in a few releases. > > I think that this is similar to your proposal except that there is only > one legacy behavior that covers both layer2 and layer3. > > What do you think?
I'm afraid we cannot just have one option to cover all legacy behavior. We need to support both L2 and L3 legacy options for non-PTAP controllers, e.g. to tunnel MPLS packets over GRE. This was the main purpose of our L3 user space tunneling patches that you just merged. With a single legacy option OVS couldn't decide whether to send an Ethernet+MPLS packet as L2 or L3 packet into the GRE tunnel. (I assume you do not suggest to keep the additional boolean tunnel option "layer3" in addition to "packet_type=legacy" to discriminate the cases). This would mean: * options:packet_type=legacy_l2: Send and receive only Ethernet frames as is. This would be the default for tunnels that can carry Ethernet (afaik all except LISP). * options:packet_type=legacy_l3: Receive L3 packets only and convert to Ethernet. Transmit Ethernet packets only by stripping the Ethernet header. This would be the default for L3-only tunnels like LISP. * options:packet_type=ptap: Send and receive any packet type supported by the tunnel as is. PTAP controllers should configure their tunnels like this. _______________________________________________ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
