I think the main issue is that when packets are being tunneled and NSH is in use, the encapsulation format (and therefore OVS port type) is not NSH - it's typically VXLAN-GPE. This is conceptually similar to MPLS over GRE, which we don't currently support without an intervening Ethernet header. However, if we did it would presumably use the existing push/pop MPLS actions.
It seems like the only way to do this cleanly for both the NSH and MPLS cases for tunneled and non-tunneled packets is to have push/pop Ethernet and push/pop MPLS/NSH actions. This would allow the headers to be built up incrementally in whatever form is appropriate. Outputting to a tunnel or a physical port wouldn't need any actions that are different at the tagging layer. One other comment, unrelated to the above discussion, is that NSH is continuing to make incompatible wire format changes. Specifically, the option length field was recently changed from representing four byte multiples to be the actual length. This brings up two questions: * Obviously the patches will need to be updated to handle this but also it means that the option format is no longer exactly the same as Geneve options. This will require some thought on how to support both protocols while maximizing code reuse. * OVS strives to maintain consistent behavior for external interfaces and it's not clear how this would be possible if the protocol continues to change in the future. On Thu, Sep 15, 2016 at 10:55 AM, Ben Pfaff <b...@ovn.org> wrote: > It's fine with me to solve Ethernet encapsulation using push and pop > actions, but I don't see why L2-in-L3 use of NSH should be any different > from any other tunnel format. > > On Wed, Sep 07, 2016 at 02:22:39PM +0000, Jan Scheurich wrote: >> 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
