Closed adferguson closed 11 years ago
For allow/deny ... these are about admission control for the flows which match patterns which are subsets of the patterns matched by the share. As long as we keep the FML logic that DENY supersedes ALLOW, I think we can make this work.
Does an allow or deny ever fail? Would it make sense to fail such a command if there is already an allow or deny issued on those flows in that share during the time period specified?
EDIT: Well, it would fail if the user lacks permissions to issue allow/deny statements on the share, but the second question still applies.
When we emit OpenFlow instead of FML, we will need to implement the appendix of the FML paper for flattening the cascades and resolving the conflicts (eg, deny overrides allow).
Ok, we now have partial & strict modes of applying the verbs (I guess they are adverbs!) ... in the strict mode, we can have allows & denys fail, but in the partial mode, they will succeed (as all partial mode commands do) but should give some feedback to the user about what happened.
This was resolved with HFTs
Rate-limit? Latency? Jitter? Allow / deny ? Also, waypoints.