Operating System: All
Platform: All

This behaviour is due to https://git.opendaylight.org/gerrit/#/c/40744/ and has been discussed on the threads:

• https://lists.opendaylight.org/pipermail/openflowplugin-dev/2016-July/005509.html
• http://meetings.opendaylight.org/opendaylight-openflowplugin/2016/openflow_plugin_meeting_july_14/opendaylight-openflowplugin-openflow_plugin_meeting_july_14.2016-07-14-15.10.html

Community to determine if this is an issue or not.

Amendment to Description:

This behaviour has been observed as recently as distribution-karaf-0.5.0-20160722.183255

Possible fix is to revert https://git.opendaylight.org/gerrit/#/c/40744/ and apply https://git.opendaylight.org/gerrit/#/c/38895/

Hi Bertrand,

Reverting this will enable the inconsistent behavior of the plugin when it comes to modifying the flow. There are two scenario when it comes to updating the flows

(1) User installs the flow, flow installs successfully on the switch, user modify the flow and it gets updated on the switch. So basically it shows that modifying the flow in data store will modify your flow.

(2) User installs the flow, but flow installation on the switch fails because of the wrong action (e.g using the port that is not available on the switch), then user modifying the flow with correct action/match, but flow installation fails, because when you send FLOW_MODE( MODIFY), to the switch, switch will reject this request if flow don't exist on the switch. So in this scenario, modifying the flow is not working.

So modifying the flow in data store is working based on the scenario.

That change done through https://git.opendaylight.org/gerrit/#/c/40744/ make this consistent. With this change, modifying flow in data store will work in both the scenario, but this has a side effect that the duration will be reset.

Hi Anil,

thanks for explaining the two scenarios. I have recently pulled in the master branch and rebased and applied patch 38895 and reverted patch 40744 and tested the two scenarios.

(1) I've installed the following flows via REST calls to the config data store, which were then successfully pushed to the switch:

root@mininet-vm:~# ovs-ofctl dump-flows s1
NXST_FLOW reply (xid=0x4):
cookie=0x1, duration=2.938s, table=0, n_packets=0, n_bytes=0, idle_timeout=65000, hard_timeout=65000, idle_age=2, priority=2,ip,nw_dst=10.0.0.2 actions=drop
cookie=0x0, duration=2.934s, table=0, n_packets=0, n_bytes=0, idle_timeout=65000, hard_timeout=65000, idle_age=2, priority=2,ip,nw_dst=10.0.0.1 actions=drop
cookie=0x4, duration=2.930s, table=0, n_packets=0, n_bytes=0, idle_timeout=65000, hard_timeout=65000, idle_age=2, priority=2,ip,nw_dst=10.0.0.5 actions=drop
cookie=0x3, duration=2.921s, table=0, n_packets=0, n_bytes=0, idle_timeout=65000, hard_timeout=65000, idle_age=2, priority=2,ip,nw_dst=10.0.0.4 actions=drop
cookie=0x2, duration=2.914s, table=0, n_packets=0, n_bytes=0, idle_timeout=65000, hard_timeout=65000, idle_age=2, priority=2,ip,nw_dst=10.0.0.3 actions=drop

I then subsequently modified the flows, in quick succession, via REST and was able to both modify the flow in the data store and also on the switch without resetting the flow duration:

root@mininet-vm:~# ovs-ofctl dump-flows s1
NXST_FLOW reply (xid=0x4):
cookie=0x0, duration=31.391s, table=0, n_packets=0, n_bytes=0, idle_timeout=65000, hard_timeout=65000, idle_age=31, hard_age=4, priority=2,ip,nw_dst=10.0.0.1 actions=dec_ttl
cookie=0x2, duration=31.371s, table=0, n_packets=0, n_bytes=0, idle_timeout=65000, hard_timeout=65000, idle_age=31, hard_age=4, priority=2,ip,nw_dst=10.0.0.3 actions=dec_ttl
cookie=0x1, duration=31.395s, table=0, n_packets=0, n_bytes=0, idle_timeout=65000, hard_timeout=65000, idle_age=31, hard_age=4, priority=2,ip,nw_dst=10.0.0.2 actions=dec_ttl
cookie=0x3, duration=31.378s, table=0, n_packets=0, n_bytes=0, idle_timeout=65000, hard_timeout=65000, idle_age=31, hard_age=4, priority=2,ip,nw_dst=10.0.0.4 actions=dec_ttl
cookie=0x4, duration=31.387s, table=0, n_packets=0, n_bytes=0, idle_timeout=65000, hard_timeout=65000, idle_age=31, hard_age=4, priority=2,ip,nw_dst=10.0.0.5 actions=dec_ttl

root@mininet-vm:~# ovs-ofctl dump-flows s1
NXST_FLOW reply (xid=0x4):
cookie=0x0, duration=43.543s, table=0, n_packets=0, n_bytes=0, idle_timeout=65000, hard_timeout=65000, idle_age=43, hard_age=3, priority=2,ip,nw_dst=10.0.0.1 actions=FLOOD
cookie=0x2, duration=43.523s, table=0, n_packets=0, n_bytes=0, idle_timeout=65000, hard_timeout=65000, idle_age=43, hard_age=3, priority=2,ip,nw_dst=10.0.0.3 actions=FLOOD
cookie=0x1, duration=43.547s, table=0, n_packets=0, n_bytes=0, idle_timeout=65000, hard_timeout=65000, idle_age=43, hard_age=3, priority=2,ip,nw_dst=10.0.0.2 actions=FLOOD
cookie=0x3, duration=43.530s, table=0, n_packets=0, n_bytes=0, idle_timeout=65000, hard_timeout=65000, idle_age=43, hard_age=3, priority=2,ip,nw_dst=10.0.0.4 actions=FLOOD
cookie=0x4, duration=43.539s, table=0, n_packets=0, n_bytes=0, idle_timeout=65000, hard_timeout=65000, idle_age=43, hard_age=3, priority=2,ip,nw_dst=10.0.0.5 actions=FLOOD

Here is the log in the switch showing the flow commands that it received:

Aug 11 15:31:31 mininet-vm ovs-vswitchd: ovs|00314|connmgr|INFO|s1<->tcp:192.168.56.101:6653: 5 flow_mods 10 s ago (5 adds)
Aug 11 15:32:31 mininet-vm ovs-vswitchd: ovs|00315|connmgr|INFO|s1<->tcp:192.168.56.101:6653: 10 flow_mods in the 13 s starting 43 s ago (10 modifications)

(2) I've installed the following flow in the config data store via REST:

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<flow xmlns="urn:opendaylight:flow:inventory">
<id>1</id>
<priority>40</priority>
<table_id>0</table_id>
<flow-name>Foo40</flow-name>
<instructions>
<instruction>
<order>0</order>
<apply-actions>
<action>
<order>0</order>
<dec-nw-ttl></dec-nw-ttl>
</action>
</apply-actions>
</instruction>
</instructions>
<match>
<ethernet-match>
<ethernet-type>
<type>2048</type>
</ethernet-type>
</ethernet-match>
<ipv4-source-address-no-mask>40.40.40.0</ipv4-source-address-no-mask>
<ipv4-destination-address-no-mask>40.40.40.0</ipv4-destination-address-no-mask> <!-- this fails to be pushed on the switch -->
<ipv4-destination-arbitrary-bitmask>255.0.255.0</ipv4-destination-arbitrary-bitmask>
<ipv4-source-arbitrary-bitmask>255.255.255.255</ipv4-source-arbitrary-bitmask>
</match>
</flow>

but this flow fails to be pushed onto the switch (running OVS 2.5.0) due to this error:

Aug 11 16:43:33 mininet-vm ovs-vswitchd: ovs|00831|nx_match|WARN|Rejecting NXM/OXM entry 0:32768:12:1:8 with 1-bits in value for bits wildcarded by the mask.
Aug 11 16:43:33 mininet-vm ovs-vswitchd: ovs|00832|connmgr|INFO|s1<->tcp:192.168.56.101:6653: sending OFPBMC_BAD_WILDCARDS error reply to OFPT_FLOW_MOD message

I then modified the flow in the config data store via REST by changing the <ipv4-destination-address-no-mask> to:
<ipv4-destination-address-no-mask>40.0.40.0</ipv4-destination-address-no-mask> <!-- this is successfully pushed to the switch -->
and the flow is successfully pushed onto the switch as an ADD.

Please let me know if the above behaviour is desirable and I will submit a new patch with the changes for review by the community.

Hi Bertrand,

This flow that you are modifying and installing again is basically changing the match construct in the flow (ip-address). Whenever you change the match, it's a new flow as per plugin, because as per openflowplugin spec, you can't modify the match construct of the flow, you can only modify the actions/instructions of the flow. As i mentioned in my previous comment, if you install a flow that has wrong actions/instructions and try to modify the flow again with correct actions/instruction, it will not work.

Hi Anil,

Sorry, I may be misunderstanding or missing a code path for the updating of flows. Would greatly appreciate some clarification. Do you mean that the logic of patch 38895 is incorrect, or that it was applied to the OFRpcTaskFactory, which no longer appears to be involved in the code path for the adding/updating of flows.

I have ported a similar fix to patch 38895 to the updateFlow() method in the SalFlowServiceImpl class. With this logic in place in SalFlowServiceImpl.updateFlow(), the flow example provided in OPNFLWPLUG-713 (with the configuration <output-node-connector>openflow:1:65535</output-node-connector>) can be successfully pushed to the switch after modifying it with a correct <output-node-connector> configuration, and existing flows on the switch can be modified without resetting the flow duration. Please let me know if you think this appears to be on the right track.

Hi Bertrand,

I think we both are on same page. In your patch, you are making a read transaction to the data store to check if the flow exist in the data store or not. It has two issues
(1) Making read call for each flow has a performance penalty. I thought of using the same approach, but because of the additional read call per flow add/update, i avoided that approach to avoid any performance penalty.
(2) This solution relies on statistics collection, but if you disable the statistics collection, your solution will behave the same way as we have today after my patch. Because in your approach it will check in the operational data store and it won't fine the hashcode for the flow and it will assume that flow is not installed on the switch and it will add the flow, which is basically what my patch is doing.

So overall, after discussing this with other committer, we thought that we should go with the approach we have currently in the plugin.

Hi Anil,

thanks for clarifying. Feel free to change this bug's Importance or close it as you see fit.