Hi, I am writing an OF 1.1 controller with applications that require the installation of a complex set of flow and group entries on a network of OF 1.1 switches. Naturally, flows are dependent on groups as they refer to group IDs in their match actions. Groups can be dependent on other groups. The OF 1.1 spec has an error code (OFPBAC_BAD_OUT_GROUP) when trying to add a flow or group that references an unknown group ID.
According to the spec, deletion of a group that has flows (or other groups?) pointing to it should result in the implicit removall of these flows (and groups?). This makes group deletion a quite dangerous operation in my eyes and I can't use it in the context of modifying an existing group. Unfortunately, the semantics of the ofp_group_mod commands (ADD, MODIFY) have beed defined differently from the corresponding ofp_flow_mod actions: While for ofp_flow_mods an ADD successfully overwrites an existing flow entry (if overlap checking is disabled) and a MODIFY_STRICT implicitly reverts to an ADD when the flow entry does not exist yet (or was deleted by the switch), the group ADD fails if the group already exists and the group MODIFY fails if the group doesn't exist yet. So, if the controller is not sure that a group entry exists (e.g. because it had temporarily lost the OF connection to the switch) it must be prepared that a group ADD or MODIFY fails and the switch returns an ofp_error message in response. The basic problem with this is that the ofp_group_mod message doesn't have a mandatory positive acknowledgement. So the controller must blindly wait for some time after sending an ofp_group_mod (ADD or MODIFY) message, just in case the switch sends an ofp_error_message. Only if there is no error until timeout, the controller can proceed sending further dependent group or flow mod messages. If an error is received, the controller must resend the corresponding other group mod command (MODIFY or ADD). This is bad for three reasons: 1. The successful (normal) case becomes very slow. 2. Controller design becomes extremely messy. 3. The timer-controlled approach is still not safe agains late error messages. Alternatively, the controller could send an ofp_group_stats_request for the group and wait for the ofp_group_stats response before sending a group ADD or MODIFY command accordingly. This is also not nice but at least avoids the long timeout delay in the successful case. But the cost is an extra message pair for every group modification. I would *strongly recommend* to change the group_mod semantics in OF 1.1 to match the flow_mod semantics. This would tremendously ease the implementation of controllers and make the OF protocol more consistent. Secondly, it would be very beneficial for future OF versions to consistently provide (positive) acknowledgment messages to all request type messages that may fail. If backward compatibility or performance is an issue, these acknowledgements could be made optional (i.e. explicitly requested by the sender with a flag). Best regards, Jan
_______________________________________________ openflow-discuss mailing list [email protected] https://mailman.stanford.edu/mailman/listinfo/openflow-discuss
