[ovs-dev] [PATCH v2] tunnel: ToS and TTL inheritance for MPLS tunneled traffic

Ben Pfaff blp at ovn.org
Wed Nov 29 01:10:55 UTC 2017


On Wed, Nov 01, 2017 at 03:38:50PM +0000, Balazs Nemeth wrote:
> From: Miklos Pelyva <miklos.pelyva at ericsson.com>
> 
> When a new outermost MPLS label is added to 'flow' the 'flow''s
> Ethernet type is changed to 'mpls_eth_type'. After the new label is
> set, the 'flow''s MPLS stack is updated, and the L3/4 fields are
> cleared to mark them invalid. This results in loosing the values of
> the 'nw_tos' and the 'nw_ttl' fields from the struct 'flow'.
> 
> Hence, it is impossible to use the ToS and TTL 'inherit' feature in
> case of MPLS tunneled traffic, because currently the values to be
> inherited are coming from the cleared (invalidated) variables of
> struct 'flow'.

OK, I spent some time and I think I understand what going on.

1. Start with some IPv4 or IPv6 packet.  It has a TTL and a TOS.
2. An MPLS label gets pushed on.  It has a TTL but not a TOS, since MPLS
   doesn't have a TOS field.
3. We send the MPLS packet to an L3 tunnel.  It has a TTL and a TOS that
   need to get initialized.

The problem is that the inner TOS from step 1 wants to get propagated to
the TOS in step 3, but it was lost in the middle.

Now that I understand the problem better, let me comment on the proposed
solution.

First, it is not much fun to have to copy nw_tos into latest_nw_tos
whenever the former might change.  I don't think it's actually necessary
to carefully analyze all the points when it might change.  It seems like
it would be OK to just copy it whenever an MPLS label gets pushed.

Second, this solution feels a little "magical".  An approach that would
feel more "natural" and more in line with usual OVS approaches would be
to introduce a new tun_tos field, which could be copied from nw_tos or
otherwise set, and then allow tunnels to configure "tos" as "flow".
Then a controller that wants to do this kind of propagation from step 1
to step 3 could easily do so.  The same approach could work for ttl
although it is not as necessary of course.

What do you think?

Thanks,

Ben.


More information about the dev mailing list