Thanks Ben, I understood the conclusion of the earlier NSH discussions around November last year (e.g. http://openvswitch.org/pipermail/dev/2015-November/061933.html and http://openvswitch.org/pipermail/dev/2015-November/061921.html) was to separate NSH encapsulation from the underlying transport tunnels like VXLAN-GPE and handle push/pop_nsh in OpenFlow.
The biggest issue for modelling NSH tunnels as tunnel ports is that the SFC controller must be able to send the NSH packets with Ethernet transport encapsulation out (to a VM) on a well-defined OF port. That basically rules out OVS tunnel ports for this use case as there is no outer IP layer and we cannot rely on the host kernel stack to route tunnel packets. I therefore believe we should stick to the agreed approach and solve the conceptual difficulties with push/pop_nsh actions. My preference would be to keep it simple for now and stay on the ground of the all-Ethernet pipeline. We can refine this once OVS implements support for packet type-aware pipeline or is generalized otherwise, e.g. when introducing support for P4. BR, Jan > -----Original Message----- > From: Ben Pfaff [mailto:b...@ovn.org] > Sent: Tuesday, 06 September, 2016 16:31 > To: Jesse Gross > Cc: Jan Scheurich; Li, Johnson; Simon Horman; dev@openvswitch.org; Miguel > Angel Muñoz Gonzalez; Manuel Buil; László Sürü; > Multanen, Eric W > Subject: Re: [ovs-dev] NSH Option 2 implementation > > On Tue, Aug 23, 2016 at 07:47:50PM -0700, Jesse Gross wrote: > > 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. > > Basically, OVS has implemented tunnels in its own fashion for far longer than > OpenFlow has had any support for tunnels. OVS might > eventually support both ways to handle tunnels but for now it makes sense to > continue implementing them in the OVS style. _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
