Operating System: All
Platform: All

This seems to be related to CONTROLLER-108

Trying to delete a flow from restconf throws the following exception:

HTTP Status 405 - Method Not Allowed

type Status report

message Method Not Allowed

description The specified HTTP method is not allowed for the requested resource.

Apache Tomcat/7.0.32

I tried the same flow addition and moification through dpctl command with cpqd switch and it does not work either.

1. utilities/dpctl tcp:127.0.0.1:6000 flow-mod table=0,cmd=add,prio=5109 in_port=1,eth_type=0x800,ip_src=9.1.1.2, apply:output=1

Flow statistics command shows flow is added:
stat_repl{type="flow", flags="0x0", stats=[{table="0", match="oxm

", dur_s="154", dur_ns="805000", prio="5109", idle_to="0", hard_to="0", cookie="0x0", pkt_cnt="0", byte_cnt="0", insts=[apply{acts=[out

]}]}]}

Deepthi: Could you try from the command line on OVS and paste in the results here as well... should be a perfectly valid flow from looking at it, wondering if there's a CPqD bug.

Ed: I tried the commands with OVS. Result is the same. There is no error and the flow is not modified. Since there is no error from the switch, it means that a matching flow entry for modification was not found.

Commands:
1. sudo ovs-ofctl -O Openflow13 add-flow s1 "table=0, priority=5109, in_port=1, dl-type=0x800, nw_src=9.9.1.2, action=output:1"

Flow statistics:
OFPST_FLOW reply (OF1.3) (xid=0x2):
cookie=0x0, duration=0.074s, table=0, n_packets=0, n_bytes=0, priority=5109,ip,in_port=1,nw_src=9.9.1.2 actions=output:1

2. sudo ovs-ofctl -O Openflow13 mod-flows s1 "table=0, priority=5109, in_port=1, dl-type=0x800, nw_src=9.9.1.3, action=output:1"

Flow statistics:
OFPST_FLOW reply (OF1.3) (xid=0x2):
cookie=0x0, duration=0.235s, table=0, n_packets=0, n_bytes=0, priority=5109, ip,in_port=1,nw_src=9.9.1.2 actions=output:1

I still see this problem (obviously since even via command line the flow cannot be modified)

We need to when a change is written to a flow check to see if the new match matches the old match. If the new match and priority matches the old match and priority, push it as a flow_mod modified. if the new match doesn't match the old match, we need to send a flow_mod delete and a flow_mod add.

This should be handled in the plugin.

If the new match does not match the existing match, the forwarding rules manager should return an error and it should be left to an application to handle this error just like EEXIST in *nix. For example, we don't allow configuration of the same vlan on the same interface twice and the OS does not attempt to hide this fact from the config app by deleting the existing vlan & adding the new one.

Pushing such application specific behavior to the plugin is needlessly adding too much complexity to the plugin and does not belong at the plugin layer architecturally.

I agree with Srikar's comment. But do we have time to implement it for Hydrogen?

Already there is gerrit @ 2760. May be we should re-visit the gerrit

Sorry gerrit @ 3894

It is unacceptable for to propogate pure openflowisms into the NB.

Semantically, a user of a 'flow programming' API has a reasonable expecation that they can modify a flow, including its match or priority. There are other kinds of flow programming APIs (like COPS) that do not have Openflows pecurliarity on flow modify. There fore it is imperative that we handle this down in the plugin where Openflowism should be isolated. The only reasonable way I can think of to do so is to have the plugin check for change to match/priority and if found send a delete and an add as OF fails to support certain valid kinds of modifications with its modify message.

Here is a scenario:
1. We add flow(flowid=20) with dst address 10.10.1.0
creationDataStore will have 10.10.1.0

2. Modify flow(flowid = 20) with dst address 20.20.1.0

So originalFlow = 10.10.1.0 and updatedFlow=20.20.1.0
creationDataStore will be 10.10.1.0 and updateddataStore=20.20.1.0

3. Modify flow(flowid = 20) again with dst address 30.30.1.0

So originalFlow = 10.10.1.0 and updatedFlow=30.30.1.0
creationDataStore will be 10.10.1.0 and updateddataStore=30.30.1.0

So if you observe the above behavior the originalFlow is always set to what is present in creationDataStore. creationDataStore is updated only once during Flow creation.

So the problem is MD-SAL needs to update the originalFlow with the right value.
Until then as discussed flow_mod for match logic will not work.

http://git.opendaylight.org/gerrit/4720

What's the latest on this bug Deepthi?

Patch submitted for review: https://git.opendaylight.org/gerrit/#/c/6645/1

Hi Is anyone looking into the patch review?

It's blocking me from pushing further test cases to Robot for integration project.

Hi Chris,

We are currently rebasing the recent changes done on the same file (OFRpcTaskHelper etc).

Also the current fix does not check for priority.

We am in the process of including adding the priority check as well and a review link will be soon submitted.

Thanks
Kamal

New Gerrit link with both priority and match checks : https://git.opendaylight.org/gerrit/#/c/7099/

https://git.opendaylight.org/gerrit/#/c/7099/