+(#) "modify" and "modify-strict" only add a new flow if the flow_mod
+ does not match on any bits of the flow cookie
+
+OpenFlow 1.2
+------------
+
+OpenFlow 1.2 makes these changes:
+
+ - Only "add" commands ever add flows, "modify" and "modify-strict"
+ never do.
+
+ - A new flag OFPFF_RESET_COUNTS now controls whether "modify" and
+ "modify-strict" reset counters, whereas previously they never
+ reset counters (except when they inserted a new flow).
+
+ MODIFY DELETE
+ ADD MODIFY STRICT DELETE STRICT
+ === ====== ====== ====== ======
+match on priority yes --- yes --- yes
+match on out_port --- --- --- yes yes
+match on flow_cookie --- yes yes yes yes
+match on table_id yes yes yes yes yes
+controller chooses table_id yes yes yes
+updates flow_cookie yes --- ---
+updates OFPFF_SEND_FLOW_REM yes --- ---
+honors OFPFF_CHECK_OVERLAP yes --- ---
+updates idle_timeout yes --- ---
+updates hard_timeout yes --- ---
+resets idle timer yes --- ---
+resets hard timer yes yes yes
+zeros counters yes & &
+may add a new flow yes --- ---
+sends flow_removed message --- --- --- % %
+
+(%) "delete" and "delete_strict" generates a flow_removed message if
+ the deleted flow or flows have the OFPFF_SEND_FLOW_REM flag set.
+ (Each controller can separately control whether it wants to
+ receive the generated messages.)
+
+(&) "modify" and "modify-strict" reset counters if the
+ OFPFF_RESET_COUNTS flag is specified.
+
+OpenFlow 1.3
+------------
+
+OpenFlow 1.3 makes these changes:
+
+ - Behavior for a table_id of 255 is now defined, for "delete" and
+ "delete-strict" commands, as meaning to delete from all tables.
+ A table_id of 255 is now explicitly invalid for other commands.
+
+ - New flags OFPFF_NO_PKT_COUNTS and OFPFF_NO_BYT_COUNTS for "add"
+ operations.
+
+The table for 1.3 is the same as the one shown above for 1.2.
+
+
+OpenFlow 1.4
+------------
+
+OpenFlow 1.4 does not change flow_mod semantics.
+
+
+OFPT_PACKET_IN
+==============
+
+The OpenFlow 1.1 specification for OFPT_PACKET_IN is confusing. The
+definition in OF1.1 openflow.h is[*]:
+
+ /* Packet received on port (datapath -> controller). */
+ struct ofp_packet_in {
+ struct ofp_header header;
+ uint32_t buffer_id; /* ID assigned by datapath. */
+ uint32_t in_port; /* Port on which frame was received. */
+ uint32_t in_phy_port; /* Physical Port on which frame was received. */
+ uint16_t total_len; /* Full length of frame. */
+ uint8_t reason; /* Reason packet is being sent (one of OFPR_*) */
+ uint8_t table_id; /* ID of the table that was looked up */
+ uint8_t data[0]; /* Ethernet frame, halfway through 32-bit word,
+ so the IP header is 32-bit aligned. The
+ amount of data is inferred from the length
+ field in the header. Because of padding,
+ offsetof(struct ofp_packet_in, data) ==
+ sizeof(struct ofp_packet_in) - 2. */
+ };
+ OFP_ASSERT(sizeof(struct ofp_packet_in) == 24);
+
+The confusing part is the comment on the data[] member. This comment
+is a leftover from OF1.0 openflow.h, in which the comment was correct:
+sizeof(struct ofp_packet_in) is 20 in OF1.0 and offsetof(struct
+ofp_packet_in, data) is 18. When OF1.1 was written, the structure
+members were changed but the comment was carelessly not updated, and
+the comment became wrong: sizeof(struct ofp_packet_in) and
+offsetof(struct ofp_packet_in, data) are both 24 in OF1.1.
+
+That leaves the question of how to implement ofp_packet_in in OF1.1.
+The OpenFlow reference implementation for OF1.1 does not include any
+padding, that is, the first byte of the encapsulated frame immediately
+follows the 'table_id' member without a gap. Open vSwitch therefore
+implements it the same way for compatibility.
+
+For an earlier discussion, please see the thread archived at:
+https://mailman.stanford.edu/pipermail/openflow-discuss/2011-August/002604.html
+
+[*] The quoted definition is directly from OF1.1. Definitions used
+ inside OVS omit the 8-byte ofp_header members, so the sizes in
+ this discussion are 8 bytes larger than those declared in OVS
+ header files.
+