On Tue, Aug 23, 2016 at 9:12 AM, Jan Scheurich <jan.scheur...@ericsson.com> wrote: >> -----Original Message----- >> From: Jesse Gross [mailto:je...@kernel.org] >> Sent: Monday, 15 August, 2016 19:12 >> >> On Fri, Aug 12, 2016 at 1:01 AM, Jan Scheurich <jan.scheur...@ericsson.com> >> wrote: >> > The only clean way to avoid that now would be to maintain the monolithic >> > push/pop_nsh semantic of the Yi Yang patch and always >> push/pop NSH header and outer MAC header together. Together with Simon's >> patch we could still achieve NSH over VXLAN-GPE, if >> the VXLAN-GPE tunnel is configured as non-Ethernet tunnel, as the unneeded >> Ethernet header would be popped at transmission to the >> tunnel. >> > >> > I believe we to decide whether we want to stick to the Ethernet-only >> > pipeline or start implementing support for packet-type aware >> pipeline in OVS for the introduction of NSH. Anything in between would be >> conceptually problematic and not in line with OF 1.5. >> >> I'm still not enthusiastic about having a combined push NSH/Ethernet action. >> I don't think that it even really supports the full NSH use >> case since at least some of the patches sent are not using VXLAN-GPE but >> directly insert the header over Ethernet. I wouldn't want to >> introduce an action that would immediately need to be replaced since we >> won't be able to change any of the public interface >> semantics once this goes in. > > I'm not enthusiastic either, but I think we should not block support for NSH > until the packet-type aware pipeline is finally implemented in OVS. One way > of stressing the monolithic nature of these actions could be to call them > "push/pop_nsh_eth". That would leave the names push/pop_nsh and push/pop_eth > available for a modular actions in the future.
Ben mentioned that he had some comments on the "OVS philosophy" here vs. OpenFlow, so that might affect things. Hopefully it will end up simplifying things somewhat. As I think you can tell, I really want to avoid situations where we don't do the right thing simply because of the time needed to implement it - this is particularly true where the change is user-visible and we'll have to live with the wart forever. I think there's been an unfortunate amount of that with the NSH patchset in the past, so let's see if we can find a clean way to handle this. _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
