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

Jean Tourrilhes jt at labs.hpe.com
Fri Jun 16 01:12:31 UTC 2017


On Fri, Jun 16, 2017 at 12:00:56AM +0000, Jan Scheurich wrote:
> 
> Hi Jean, thanks for your feedback.

	My pleasure ;-)

> The usual pattern is that controllers (just like OVS) add protocol
> support for an OF wire protocol version without implementing all new
> features.

	With every new version of OpenFlow, some features are
optional, and some features are mandatory. For example, when going
from 1.0 to 1.3, controllers could not ignore the multiple table
support, and could not ignore OXMs. Similarly, when going from 1.3 to
1.4, controllers can't ignore the new reasons for packet-in, and the
more flexible structures. And when going from 1.4 to 1.5, controllers
can't ignore packet-type.
	I disagree that EXT-112 is optional in 1.5. If you read 7.3.6
and 7.4.1 about "data", you can't interpret and decode "data" without
looking at the packet-type, so supporting packet-type in packet-in and
packet-out is pretty mandatory to me. Section 7.2.3.11 is also full of
"must" ;-)

> As PTAP is a pretty major semantical addition, I think it would not
> be wise to rely on controllers to handle PTAP (especially
> non-Ethernet packet types) just because they can talk OF 1.5 wire
> protocol.

	First, that major semantical addition is part of 1.5, so
I don't see how 1.5 implementation can avoid it and claim compliance
with 1.5. All Ethernet assumptions in the spec were explicitly removed
in EXT-112, starting with the glossary and prerequisite (I can send
you the diff). There is no place that says "only Ethernet", so having
multiple packet types is integral to 1.5.
	I did not say that all 1.5 implementations must accept all
packet types and the full PTAP. But all must check the packet-type
field and figure out if they like it or must throw an error.

	Second, the main reason controllers will upgrade to 1.5 is to
support PTAP. None of the other exclusive 1.5 features is gaining
traction (most 1.5 features are available in 1.3 extensions and
NXMs). So equating 1.5 and PTAP is a safe bet.
	It is early enough in 1.5 implementations that whatever you
decide for 1.5, other implementation will have to follow suite. So,
set the right example ;-)

> We believe that an OF 1.3 controller extended with support for PTAP

	I personally hate that, because now you truly have semantic
inconsistency, you can't do that without violating the 1.3
spec. Further, the controller and the switch have no way to know if
it's talking to PTAP partner or not, other switches may use alternate
solutions for enabling and supporting PTAP in 1.3, so I foresee that
interrop will be a mess.
	I believe that implementing 1.5 on the controller side is
going to be easier than implementing PTAP proper, so making 1.5
a requirement for PTAP is IMHO the simpler and saner solution.
	Yeah, I know that some controllers can't upgrade to 1.5 yet,
and that's pretty much the only reason you have to hack it in
1.3. However, Ryu and Loxigen support 1.5.1 already, so really there
is no excuse in my mind. I believe that it is a short term expediency
that will bring long term consequences for interrop.

> A single property looks attractive at first glance. The issue we see
> with that is that it can break backward compatibility for legacy
> controllers as we cannot rely on the negotiated OF versions as
> secure indicator that sending L3 Packet In messages is OK.

	Please check again 7.4.1. Pretty clear cut to me, a 1.5
controller must expect non-Ethernet packet and read packet-type (but
it does not have to decode or accept those packets). If the controller
throws an error on packet-in, you can flip the config on the
tunnel/port.

	Whatever you do with 1.3 will remain non-standard, so it's
probably OK to have warts and extra config. But, for 1.5 do it right,
remove special modes and switches, it will be simpler long term.

	Regards,

	Jean


More information about the dev mailing list