[ovs-dev] NSH Option 2 implementation

Jan Scheurich jan.scheurich at ericsson.com
Fri Aug 12 08:01:46 UTC 2016


Hi, 

I still think that from an OpenFlow perspective it is conceptually broken to have the same OXM or NXM fields refer to packet header fields in the case they are part of the packet header and to some kind of "metadata" fields if they are not. It's basically the same problem as I high-lighted for the NSH match fields in my earlier post (http://openvswitch.org/pipermail/dev/2016-July/075329.html).

OpenFlow is quite strict about pre-requisites. You are not allowed to match on or set fields whose pre-requisite is not fulfilled (e.g. eth_type=0x800 for all IPv4 fields). Up to OF 1.4 any packet in the OF (and OVS) pipeline always had a MAC header, so access to dl_src|dst and eth_type was implicitly possible always.

In OpenFlow 1.5 this generalized this with the introduction of the packet-type aware pipeline, so that OpenFlow can properly deal with non-Ethernet packets (e.g. MPLS, IPv4, etc. NSH would be a natural application too). For that OF 1.5 introduces the new OXM field PACKET_TYPE, which is used to express pre-requisites. In OF 1.5 the pre-requisite for matching on or setting MAC fields is PACKET_TYPE=Ethernet.

Now, OVS hasn't implemented support for packet-type aware pipeline (yet), so it assumes the MAC header is always present (even if it isn't any longer with Simon's patch, if the packet has been received from a non-Ethernet port). That's why it allows setting MAC address fields in that situation.

Conceptually on OF level, what Simon's patch does is to insert an empty MAC header when the packet is received from a non-Ethernet port to fulfill the requirement that every packet in the pipeline is an Ethernet packet, and to pop the MAC header when transmitting a packet to a non-Ethernet port. 

The current implementation differs from that, as the actual pushing of a missing MAC header to the packet buffer happens only just in time when transmitting to an Ethernet port. But the fields are always present in the struct flow and can be matched on and set.

This is rather confusing (and lead me to believe that Simon's patch was a first step towards packet-type aware pipeline, which was obviously wrong). I don't really see a benefit of doing so compared to actually pushing and popping the Ethernet header directly on ingress/egress from/to a non-Ethernet port.

At any rate, with explicit push/pop_nsh and push/pop_eth actions we are definitely leaving the safe ground of the all-Ethernet OF 1.3 and venture into the packet-type aware pipeline (without calling it that). 

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.

BR, Jan

> -----Original Message-----
> From: Li, Johnson [mailto:johnson.li at intel.com]
> Sent: Friday, 12 August, 2016 03:55
> >
> > On Thu, Aug 11, 2016 at 12:58:44PM +0000, Jan Scheurich wrote:
> > > Hi Simon
> > >
> > > > > The implicit push_eth action introduced by Simon in his L3
> > > > > tunnel port patch mainly ensures the presence of the 14 byte MAC
> > > > > header on ports where this is a must for syntactic
> > > > > interpretation of the packet. It did not worry about if the
> > > > > resulting packet was semantically
> > useful or not.
> > > >
> > > > In the context of my patchset it is possible to set the MAC
> > > > addresses (to something non-zero) using a set-field (or similar)
> > > > action. Is that
> > facility of use here?
> > >
> > > I don't understand how this can work. The implicit push_eth action
> > > is inserted
> > just before sending an L3 packet to an L2 port by means of an output action.
> > How can the OF controller modify the newly inserted SMAC and DMAC
> > fields with set_field actions after the output action?
> >
> > I can double check and possibly its conceptually a bit broken but at
> > least in the context of the l3 VPN patchset I believe you can set the
> > ethernet fields (e.g. just before output) even though the packet has no ethernet header at that point.
> >
> [Li, Johnson] Yes, I double confirm that we can use the mod_dl_[src|dst] or Set_dl_[src|dst] flow actions to set the MAC addresses before
> outputting to The normal L2 port. That's because the modify/set [src|dst] action will just Compose the flows and the implicit push_eth
> action is committed just before The compose of output action, and the push_eth action uses the addresses in The struct flow which are set
> before, so the dataplane flow will push an Ethernet header with non-zero addresses.
>
> > Given the way translation works in ovs-vswtichd this makes some sense.
> > From an OpenFlow point of view perhaps less so.



More information about the dev mailing list