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

Jean Tourrilhes jt at labs.hpe.com
Thu Jun 15 18:38:04 UTC 2017


Jan Scheurich wrote :
> 

	Just a warning. I forgotten everything about my code, so those
are only high level thougts.

> 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:

	The way this is usually done by OpenFlow and OVS is by using
the OpenFlow version negociated by the switch. This would work
beautifully here :
	If the controller negotiate 1.4 or earlier, the switch deals
with it in "legacy" mode.
	If the controller negotiate 1.5 or later, the switch deals
with it in "ptap" mode.

	A few more details...
	Requirement (1) is not valid for 1.5 controllers. There is no
excuse for a controller supporting 1.5 to no support packet type, it's
part of the spec ;-)
	I claim that a switch can't properly support EXT-112/PTAP in
OF prior to version 1.5. This is why EXT-112 was not ported to OF 1.3
as an extension. For example, prior to 1.5 the controller can't do
packet-out on a PTAP switch, which is pretty major.
	There is no "the controller", there is "one of the
controllers". Even ovs-ofctl is effectively a controller. The switch
has to deal with a mix of "legacy" and "ptap" controllers. So,
a single modal switch won't work, it needs to be a per-controller
setting.
	I think a "legacy" controller can't work with PTAP flow
entries and PTAP packet-in. Section 7.1.3 of OF 1.3.5 can only help so
much. Converting those to "ethernet" when sending to the controller is
dodgy, so IMHO the only way is to supress them. I don't remember what
I did in my prototype patch.
	A tunnel/port setting seems an easy way to avoid a lot of
complexity. It's annoying to have such setting, it increases confusion
and chances of misconfiguration. The alternative would be for every
flow entry set by a non-PTAP controller to be duplicated as an
Ethernet and L3 flow. Yuck.
	IMHO, there is no way for a "legacy" controller to manage
a "ptap" L3 tunnel.

> You say "tunnel ports configured as layer3 can only send and receive
> L3 packets." without detailing what that means.

	The switch need to make sure that only the appropriate packet
types are sent on the tunnel, VxLAN can not encaps L3 packets and LISP
can not encaps L2 packets, and GRE can encaps both L2 and L3.
	In most cases, the tunnel knows the encaps it's dealing with,
so in theory it could check the outgoing packet type and drop
offending types itself. Same thing in reverse when packet out of the
tunnel must be tagged with the proper type. Again, in most cases the
decapsulation knows what packet type it receives and can select the
tag.
	I guess, it depends how and where you want to implement such
filtering/tagging, and what kind of enforcement. OpenFlow has always
been "let the controller shoot itself in the foot".

> 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".

	It's clear to me that having both a bridge property
(legacy-l3-tunnel) and a port property (layer3) is confusing, not only
for the user but also for the implementers ;-) I don't see why you
need to have a setting for the whole bridge, as it's really a property
of the specific port.
	I can even imagine some bridges mixing up some tunnels in
legacy mode and some tunnels in ptap mode. Let's go crazy.
	That is why you propose to have the following per-port
property, and no per-bridge setting :
		1) layer3=layer2-only		// Legacy L2
		2) layer3=layer3-to-ethernet	// Legacy L3
		3) layer3=versatile		// PTAP aware

	But, I believe you can go one step further in the
simplification. You just need to realise that (1) and (3) are
effectively the same thing, if you assume the port knows what it is
doing. There is no point in denying non-L2 outgoing packets at the
property level in (1), because the encaps itself will take care of it
(can't encode it, drop). And if a tunnel in (1) generate an incomming
PTAP packet, OVS classifier will do the right thing (match nothing,
drop, can't packet-in to <1.5 controller).
	So, in conclusion, you just need a single per port boolean,
and no per-bridge setting :
		convert-to-ethernet=true/false

	Regards,

	Jean


More information about the dev mailing list