[ovs-dev] NSH Option 2 implementation

[Mooney, Sean K]

> -----Original Message-----
> From: dev [mailto:dev-bounces at openvswitch.org] On Behalf Of Jesse Gross
> Sent: Monday, August 15, 2016 6:12 PM
> To: Jan Scheurich <jan.scheurich at ericsson.com>
> Cc: dev at openvswitch.org; Manuel Buil <manuel.buil at ericsson.com>; Simon
> Horman <simon.horman at netronome.com>; László Sürü
> <laszlo.suru at ericsson.com>; Miguel Angel Muñoz Gonzalez
> <miguel.angel.munoz.gonzalez at ericsson.com>; Multanen, Eric W
> <eric.w.multanen at intel.com>
> Subject: Re: [ovs-dev] NSH Option 2 implementation
> 
> 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.
[Mooney, Sean K] sorry I don’t know the context of the rest of the thread
But from an neutron ovs agent point of view I think having separate push/pop nsh and push
Pop Ethernet would make the most sense. nsh with Ethernet transport is much
More appealing give how openstack tenant network already work.
Vxlan-gpe with openstack would end in a double encaped packet on the wire.
The vxlan-gpe encapsulation + the tenant network encapsulation(flat,vlan,vxlan,geneve...).
> _______________________________________________
> dev mailing list
> dev at openvswitch.org
> http://openvswitch.org/mailman/listinfo/dev