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. Jiri _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
