[ovs-dev] [PATCH 15/31] fixup: Change from global modal behavior to L3 tunnel only mode.

Ben Pfaff blp at ovn.org
Fri Jun 16 04:39:19 UTC 2017


On Wed, Jun 14, 2017 at 10:48:50PM +0000, Jan Scheurich wrote:
> We do understand your motivation for proposing this. But such change is a significant and requires careful consideration. We need to satisfy four main requirements:
> 
> 
> 
> 1. Legacy controllers that are not packet-type aware must not be affected by the introduction of packet_type in OVS. The externally visible behavior of OVS must not change as long as OVS used in "legacy" mode:
> 
> * Matching works exactly as without support packet_type as long as the pipeline handles only Ethernet packets.
> 
> * The controller shall not be exposed to unexpected packet_type fields in e.g. flow or packet in messages.
> 
> 
> 
> 2. Packet type-unaware controllers shall be able to use legacy L3 tunnels as in the past (LISP OVS 2.7, or with the just merged series for L3 tunneling in user space), i.e. implicit conversion to/from Ethernet for processing in the pipeline without controller involvement.
> 
> 
> 
> 3. Packet-type aware controllers shall be able to use versatile tunnel ports directly without implicit conversion of packet types through OVS.
> 
> 
> 
> 4. The tunnel handling logic should be easily understandable not only for OVS experts but also for controller developers of the two camps (packet type-aware and unaware).
> 
> 
> 
> We think backward compatibility requirement (1) can be fulfilled even
> if an OVS bridge is always packet type-ware, provided that the default
> packet_type (0,0) is filtered away in all OF matches sent out by OVS
> (flow messages and packet in). 

This is what OVS does in the packet set I have proposed.

> (Note: It is not quite obvious that packet type-aware controllers will
> recognize flows if they have explicitly included a packet_type=(0,0)
> match in the flows they sent. But we have the reciprocal problem in
> our previous patch also).

Related problems exist already, since OpenFlow does not define a
canonical form of flow matches.  For example, OXMs can appear in any
order that satisfies prerequisites, which leads to a large number of
valid permutations in many cases.  I have been surprised for a long time
that OVS has received few bug reports in this area; I suspect that
either controllers tolerate OVS's particular foibles here or that
controllers tend to identify flows via cookie.

> Regarding your proposed renaming of the alternative bridge property:
> We think the name used in the OVSDB schema XML "legacy-l3-tunnel" (or
> perhaps "legacy-l3-tunneling"?) is more appropriate than the name
> "legacy-l3-pipeline" that is actually used in the code (and with
> negation between OVSDB and ofproto).

I'm happy to do that renaming.

> It seems clear that (2) and (3) together require some config knob to
> control the implicit packet type conversion for legacy controllers. If
> bridge property packet-type-aware is not available for this, we either
> need a different bridge property (as in your proposal) or we have to
> configure this per port.
> 
> 
> We can assume that the legacy L3 tunnel handling behavior (2) is
> set. In your proposal this is selected through
> "legacy-l3-tunnel=true". Tunnel ports operating in this mode are
> either L2 only or L3 only and the behavior is determined through the
> "layer3" option per tunnel. The semantics are summarized by the table
> below:
> 
> 
> 
> layer3                    Rx from tunnel                                                  Tx to tunnel
> 
> 
> false                      Ethernet packets are processed as is,       Ethernet packet are sent as is,
>                                 L3 packets are dropped.                                L3 packets are dropped.
> 
> 
> true                       L3 packets are encapsulated in                   The Ethernet header is stripped
>                                 dummy Ethernet header for pipeline       before transmission to tunnel,
>                                 processing,                                                         L3 packets are dropped.
>                                 Ethernet packets are dropped.
> 
> 
> 
> The new L3/versatile tunnel port handling for packet-type-aware controllers is as follows:
> 
> 
> 
>                                 Rx from tunnel                                                  Tx to tunnel
> 
> 
> 
>                                 All packets that can be mapped to a         All packet types are sent as is w/o
>                                 known packet type (0,0) or (1,x) are         implicit type conversion. If the tunnel
>                                 processed as is.                                                 does not support the packet type as
>                                 Other packets are dropped.                        payload, packets are dropped.
> 
> 
> 
> Our understanding is that you intend to apply this behavior for
> "legacy-l3-tunnel=false". It is not clear from the documentation
> (patch 20/31) what the meaning of the "layer3" tunnel option should be
> in this case. You say "tunnel ports configured as layer3 can only send
> and receive L3 packets." without detailing what that means.
> 
> 
> 
> In our view there are only three possibilities that might make some sense:
> 
> 
> 
> 1. Ignore "layer3" option when "legacy-l3-tunnel=false" and always
> apply the above handling of versatile tunnels. As the "layer3" option
> was introduced to decide the transmit behavior for versatile tunnel
> protocols in legacy L3 tunneling, it seems logical to not attach an
> artificial meaning to it in the new L3 tunneling scheme built on
> packet_type.
> 
> 
> 
> 2. Apply above handling of versatile ports for
> "legacy-l3-tunnel=false" and "layer3=false". For "layer3=true" apply
> the same handling as for versatile ports but limit send and receive to
> L3 packets only and drop Ethernet packets. This would be consistent
> with the statement that the port is limited to L3 packets, but it
> seems to add little value to be able to "castrate" a versatile tunnel
> port to L3 by configuration. Have you got a use case in mind?
> 
> 
> 3. Apply above handling of versatile ports for
> "legacy-l3-tunnel=false" and "layer3=false". For "layer3=true" ignore
> that "legacy-l3-tunnel=false" and apply the same implicit conversion
> to/from Ethernet in the pipeline as for legacy L3 tunneling. It seems
> rather counter-intuitive to do this when legacy L3 tunneling is turned
> off.
> 
> 
> 
> So, from the above we would tend to favor option 1. In your code you
> actually implement a mixture of 2 and 3: implicitly convert to
> Ethernet at Rx from layer3 tunnel but transmit Ethernet packets as is
> to layer3 tunnel. We believe this was unintentional.

The mixture was unintentional.

> The alternative to having both bridge property "legacy-l3-tunnel" and
> a port property "layer3" would be to go for a single port property
> "tunnel-mode" with three values "layer2" (default), "layer3" and
> "versatile". "layer2" tunnel ports would only send and receive
> Ethernet packets as is. "layer3" tunnel ports would send and receive
> L3 packets with implicit conversion from/to Ethernet in the
> pipeline. Finally, "versatile" tunnel ports would send receive any
> type of supported packet as is without implicit conversion. In future
> versions of OVS the default could be changed to "versatile".
> 
> 
> We think that this approach would also fulfill requirements 1, 2 and
> 3. Our feeling is that this approach would also be somewhat easier to
> explain to users. It would not be backward compatible to the just
> introduced Boolean "layer3" flag, but that has not been released yet,
> so perhaps it would be ok.

This is not so different in spirit from Jean's proposal, I believe.

Overall, the important factors here seem to be:

  * Backward compatibility, at least for some number of releases, in the
    following areas:

      (a) LISP tunnels should remain supported in their existing form,
          which treats them as Ethernet.

      (b) Other tunnels that can encapsulate various inner protocols,
          should by default only send and receive only Ethernet.

  * With an appropriate controller, any kind of encapsulated protocol
    should be supported over a tunnel.  Full support may be possible
    only with OpenFlow 1.5, but we also hope for some provisions for at
    least limited support with earlier versions of OpenFlow (perhaps
    using Open vSwitch extensions if valuable and necessary).

I propose:

  * options:packet-type=legacy requests legacy behavior on a tunnel,
    that is, requests behavior (a) or (b) depending on the particular
    kind of tunnel.

  * options:packet-type=ptap requests versatile behavior using the
    packet_type feature on a tunnel.

For now, the default for all types of tunnels would be "legacy", but
with proper forewarning to our users we could possibly change the
default to "ptap" in a few releases.

I think that this is similar to your proposal except that there is only
one legacy behavior that covers both layer2 and layer3.

What do you think?


More information about the dev mailing list