Operating System: Linux
Platform: Other

Right - this is currently the default behavior. If there are already some flows/meters/groups on device when connection established then controller will just reflect those in DS/operational (flows will get an alien id - e.g. "#UF$TABLE*0-1") without touching them. This is especially useful in case of frequent controller restarts or device reconnections.

There was plan for implementing feature of clean-up upon connection established but that should be active based on parameter. Unfortunately this was never implemented.

Thanks Michal for the response.But what if when the tcp connection between the controller and the switch gets severed, the existing flows on the controller are modified or deleted as per business logic of the application.

Now when the switch connects back , we have additional/conflicting flows that might lead to traffic being black-holed or dropped.This might not be the desired scenario.

Is there a plan for cleanup upon establishment feature, anytime in the future ?

I see.
Regarding roadplan - please have a look at these:

https://wiki.opendaylight.org/view/OpenDaylight_OpenFlow_Plugin:Lithium_Backlog
https://wiki.opendaylight.org/view/OpenDaylight_OpenFlow_Plugin:Potential_Beryllium_Items

I guess there is currently no plan for that. This shall be discussed on ofPlugin weekly meeting.

added to Beryllium potential items wiki

Muthu has picked this up.

Gerrit - https://git.opendaylight.org/gerrit/#/c/27382/ - to be reviewed

Changed to waiting for review

Hi, in comment #2 there is also modification mentioned. I guess this is not covered in the proposal.

What is the difference in result when comparing this strategy and simple device cleanup upon connected?

Hi Michal,

This is mainly to accommodate the case where we do not want to disturb the data-path of already installed flows. If we do a full clean-up, it can result in traffic-drop

Ok,
can this feature be turned on/off for session?
Is there any specific reason why is this incorporated in FRM?

Hi Michal,

>> can this feature be turned on/off for session?
Currently not. I see your point in having this switch. I will work on introducing the same .

>> Is there any specific reason why is this incorporated in FRM?
There are two key aspects

• detecting if a flow/meter/table provisioning attempt is being made when switch is in disconnected-state is realized with minimal changes in FRM
• Checking if there are any flows/meters/groups in stale-state and sending corresponding delete messages is logically part of reconciliation function. Since FRM currently performs major part of provisioning function, it would be a more appropriate module to have these changes.

Hope we are in sync

• Muthu

Adding gerrit link for ready-reference

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

Uploaded patch-set addressing Michal's comment of making the "stale-marking" function configurable via Config Subsystem

Michal - can you review?

Michal has reviewed this - it is good to merge (either Abhijit or Anil can merge).

Marked as fixed as the code change is merged.