Handling flow consistency after a new TCP/OpenFlow connection

[jab1982]

In production, three situations might lead to a TCP/OpenFlow session disconnection: (1) switch reloads, (2) issues in the control plane communication (TCP reset), or the SDN controller reloads (3). When the switch reloads (1), its forwarding table will be empty, and the Kytos/FlowManager/MEF E-Line will need to install all flows in that switch (and that switch only). When there is a control plane communication issue (2), it is very plausible that the forwarding table wasn’t changed and flow entries are still operational. When the SDN controller reloads, switches' forwarding tables aren't affected, and the SDN controller just needs to confirm that forwarding tables weren't changed for any reason.

To find out the “new switch” forwarding status, after a Hello/FeatureReply, the Kytos/TopologyManager/other should collect the switch’s existing flow entries (via MultipartRequest/Flow) and compare with the FlowManager’s Storehouse data. If the switch reports no flows, all flows must be pushed down to the switch. If the switch reports some flows, ONLY the missing/misconfigured flows should be pushed down to the switch. This approach would prevent the OpenFlow counters of being reset.

[viniarck]

Team, FYI, this is closely related to #33 and partly related to #32 and #41.

[ajoaoff]

This issue should not be solved in mef_eline, I think this belongs to of_core.