[OPNFLWPLUG-660] Li Migration: Problems to detect the removal of flow entries Created: 24/Mar/16  Updated: 27/Sep/21  Resolved: 21/Jul/16

Status: Resolved
Project: OpenFlowPlugin
Component/s: General
Affects Version/s: None
Fix Version/s: None

Type: Bug
Reporter: Hideyuki Tai Assignee: Unassigned
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issue Links:
Duplicate
is duplicated by OPNFLWPLUG-705 openflowplugin: FlowRemoveEvent messa... Resolved
External issue ID: 5602
Priority: High

 Description   

Target
------

Target source code: master branch of March of 2016
Target feature: OFP-Li (OpenFlow Plugin Lithium design)
Target data: flow-node-inventory:table in the operational DS
Related OpenFlow message: FLOW_REMOVED

Problems
--------

With the OFP-Li, applications need to use operational DS (flow-node-inventory:table) to get information about flow entries installed in OpenFlow switches.

In my understanding, when statistics manager of the OPF-Li is installed, the flow entry information on the operational DS is updated only by the statistics manager.
And, the statistics manager does not use FLOW_REMOVED to update the flow entry information in the DS.

As a result, with the current implementation of the OFP-Li, applications face the following two problems to detect the removal of flow entries.

1. It takes so long time (several seconds) to detect the removal.
2. It is possible that applications fail to detect the removal.

First, when the statics manager is installed, the OFP-Li does not update the operational DS on the event of FLOW_REMOVED.
Instead, the statistics manager updates (removes the flow entry from) the operational DS only based on the statistics information which the statistics manager gets from switch.
However, by default, the statistics manager gets the statistics information from the switch at intervals of several seconds.
Therefore, it takes several seconds for applications which listen data change on the operational DS to detect the removal of a flow entry after the flow entry is actually removed from the switch.

Second, when an application installs a flow entry whose timeout is a few seconds, it is possible that the statistics manager could not be aware of the installation and removal of the flow entry.
That's because the statistics manager does not use the notification of FLOW_REMOVED to update the operational DS.
As a result, the application would fail to detect the removal of the flow entry.



 Comments   
Comment by Hideyuki Tai [ 24/Mar/16 ]

VTN project requests the OpenFlow Plugin project to provide a way which does not have the above two problems in Boron.

We think one candidate solution for the problems is that the OFP-Li implements a YANG notification which notifies its applications of the removal of a flow entry on the event of receiving FLOW_REMOVED message from a switch.

Comment by Kamal Rameshan [ 11/Apr/16 ]

From the code, the FlowRemoved message is processed by OFP and the same is removed from the operational.

I dont see any notification raised to be consumed by the apps.

Comment by Shuva Jyoti Kar [ 10/May/16 ]

Hi Kamal and folks,

can we publish a flowremoved notification from the place where we receive the flowremoved message and intimate the listeners.

Its taken that notifications will not be guaranteed, but just as experimenters and packet-in s can we shoot up an notification ?

Comment by Shuva Jyoti Kar [ 10/May/16 ]

A patch for the same:

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

Comment by Hideyuki Tai [ 08/Jun/16 ]

I've submitted an additional patch for this problem.
https://git.opendaylight.org/gerrit/#/c/39906/

Could a committer review and merge the patch?

Comment by Shuva Jyoti Kar [ 09/Jun/16 ]

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

Comment by Abhijit Kumbhare [ 21/Jul/16 ]

This has been added/fixed.

Generated at Wed Feb 07 20:33:03 UTC 2024 using Jira 8.20.10#820010-sha1:ace47f9899e9ee25d7157d59aa17ab06aee30d3d.