This policy matches all IP traffic, modifies the source IP to be 10.0.0.100 and forwards the result out port 1, and modifies the destination IP to be 10.0.0.0 and forwards the result out port 2.
In general, it's not possible to apply a modification, forward the result, then undo the modification and apply a different one (as in the policy above). However, imagine we see some packet with nwSrc == 192.168.1.1. If we match it exactly, we can do the following:
Some modifications cannot be deployed to OpenFlow 1.0 switches. For example, consider the following policy:
dlTyp 0x0800 ==> modify [(1, nwSrc 10.0.0.100), (2, nwDst 10.0.0.0)]
This policy matches all IP traffic, modifies the source IP to be 10.0.0.100 and forwards the result out port 1, and modifies the destination IP to be 10.0.0.0 and forwards the result out port 2.
In general, it's not possible to apply a modification, forward the result, then undo the modification and apply a different one (as in the policy above). However, imagine we see some packet with nwSrc == 192.168.1.1. If we match it exactly, we can do the following:
(dlTyp 0x0800 <&&> nwSrc 192.168.1.1 ==> modify [(1, nwSrc 10.0.0.100), (2, nwSrc 192.168.1.1 <+> nwDst 10.0.0.0)]) <+> dlTyp 0x0800 ==> modify [(1, nwSrc 10.0.0.100), (2, nwDst 10.0.0.0)]
Because we match the source IP exactly, we can add a modification to reinstate it, essentially undoing the previous modification.
(Note that this example assumes that the modification/forward actions are done in order.)
We can use reactive specialization to install the specialized rules as new flows are matched.