Hi Jean, thanks for your feedback. > 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 ;-)
The usual pattern is that controllers (just like OVS) add protocol support for an OF wire protocol version without implementing all new features. 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. > 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. We believe that an OF 1.3 controller extended with support for PTAP and EXT-382/Generic encap/decap for Ethernet is fully equipped (EXT-382 is the next patch series we will post). It can emulate the OF 1.5 Packet Out for non-Ethernet packets using the OF 1.3 Packet Out with an Ethernet packet and include a decap action to remove the unwanted Ethernet header before output. > 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. As long as OVS is only configured with legacy tunnel ports and programmed by legacy controllers, all packets in the pipeline will be Ethernet and legacy controllers will not be subject to PTAP packet ins. Combining legacy controllers, PTAP controllers and versatile tunnels in the same bridge can in my eyes never work and should be considered misconfiguration. > 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. Agreed. Legacy controllers can handle L3 tunnels only in the legacy way supported by OVS: L3 packets are implicitly converted to/from Ethernet at rx/tx, so that the pipeline only deals with Ethernet packets. > 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". Yes, for PTAP tunnels OVS does the mapping between tunnel payload and pipeline packet type automatically, and drops packets for which such mapping is not defined or not implemented. > 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. We tend to agree here :-) > 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 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. We would need an additional per-controller flag for that. So we'd like to stick to a three-valued tunnel port property, but we are very much open for alternative naming proposals to "mode=layer2|layer3|versatile", for example "mode=legacy-l2|legacy-l3|packet-type-aware". _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
