[ovs-dev] NSH Option 2 implementation

Jan Scheurich jan.scheurich at ericsson.com
Tue Aug 23 16:12:56 UTC 2016


> -----Original Message-----
> From: Jesse Gross [mailto:jesse at kernel.org]
> Sent: Monday, 15 August, 2016 19:12
> 
> On Fri, Aug 12, 2016 at 1:01 AM, Jan Scheurich <jan.scheurich at 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.

From use case perspective, the monolithic actions should be sufficient:
1. NSH over Ethernet (e.g. on local VM ports): 
push_nsh_eth, set fields for NSH and outer MAC headers, output to Ethernet port
2. NSH over VXLAN-GPE (for remote SFC nexthops):
push_nsh_eth, set fields for NSH header, output to VXLAN-GPE tunnel port configured as non-Ethernet port
3. NSH packets received from a non-Ethernet VXLAN-GPE tunnel conceptually have a dummy Ethernet header so that the pop_nsh_eth action can be applied. 

The last use case would put some requirements on the interaction with Simon's L3 port patches, unless their implementation were changed to add the missing L2 header directly on entry from a L3 port.

@Simon: Have you considered that kind of simplification of your patches? 

BR, Jan



More information about the dev mailing list