On Thu, Feb 25, 2016 at 10:13 PM, Jiri Benc <jb...@redhat.com> wrote: > On Thu, 25 Feb 2016 17:32:28 -0800, Jesse Gross wrote: >> The thing that bothers me about this is that it's not really a binary >> split between Ethernet and IP. L2 "obviously" means Ethernet (although >> theoretically there could be other things), but L3 means IPv4, IPv6, >> MPLS, NSH, etc.? That is weird. > > Depends on the point of view. It's a packet without (any) L2 header. > You're right that MPLS or NSH are not understood as L3, however they're > not L2, either. So let's call this mode "L2-less" or so? > >> From a non-OVS kernel perspective, setting L2 basically means that you >> want to do ARP on the interface and L3 is no ARP. However, if the >> tunnel is sending and receiving some additional tag then it's not >> really going to work directly in L3 mode. > > It's still L2-less. Meaning no neighbor resolution. There's no > difference between MPLS, NSH and IP wrt. how the packet is sent. > >> In the OVS case, you will definitely need to have different flows >> depending on the inner packet type. However, the most flexible way to >> handle this is by exposing it through the flow itself - it's not >> necessarily best to do this through the port, especially if it is not >> fully specific. > > I'm not sure I follow. But although you don't get an Ethernet header > from such port, you do get an ethertype of the packet (in the kernel, > it's skb->protocol). It should be quite straightforward to construct > flow from it. > >> Finally, I agree that it would be nice to be able to handle multiple >> types of encapsulated data at the same time. It seems difficult, or at >> least more complex, to achieve this with multiple ports. Each would >> try to register to the same handler and this would fail unless there >> is some kind of additional registration mechanism. > > At least in the kernel, I don't see a way to do it cleanly. The > net_device has to be usable outside of ovs, this includes things like > tcpdump working correctly.
I think what we can do is rename L3 mode to "no_arp" or something like that since I believe that's the only difference between L2 and L3 mode as currently defined. In this mode we could still pass fully formed Ethernet frames to the netdevice input/output. To me this is exactly analogous to passing MPLS or NSH to the stack - it won't inherently know what to do with it unless there is some kind of external processing but the data is there in the packet and could be decoded by normal tools. Since OVS would be explicitly manipulating the Ethernet headers through push/pop actions, it doesn't need any external resolving. Therefore, devices attached to OVS could always be put in this "no_arp" mode and we would be able to handle simultaneous traffic of different type. _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
