search

kytos / mef_eline

Kytos NApp to create and manage point-to-point L2 circuits
https://napps.kytos.io/kytos/mef_eline
MIT License
3 stars 14 forks source link

Handling flow consistency after a new TCP/OpenFlow connection #88

Open jab1982 opened 5 years ago

jab1982 commented 5 years ago

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 commented 5 years ago

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

ajoaoff commented 4 years ago

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