This group is locked. No changes can be made to the group while it is locked.
Re: [controller-dev] OVSDB, SFC and clustering
|
Reinaldo Penno <rapenno@...>
Summarizing what we just discussed on the phone… In steady state every switch in OVSDB’s operational store has an associated SFC abstraction called SFF in SFC’s configuration data store. This SFF device is created by listening to OVSDB operational tree changes. There is a lot of code to listen to change on bridges, tp-ids, node-ids, and map to SFC abstractions. The user can change this SFF if needed by creating data plane locators, using it in services paths, etc. These changes are propagated to OVS switch by writing to OVSDB config store. This is still the design we discussed originally for the new OVSDB MD-SAL<->SFC. Now, 1 – ODL reboots while OVS switch was still connected 2 – At this point all OVSDB operational store is gone 3 – But SFC was never notified. From SFC perspective all switches are still good, traffic is flowing, customer is happy. The main points: If switch reconnects, you need to reapply all data to operational store. Specially since switch configuration could have change across ODL reboots (stuff deleted or added). So, a complete write overwrite would be needed. Now, let’s suppose switch never reconnects. How will ever SFC be notified of switch gone? You can not delete something that is already gone. The listener will not get triggered Thanks, From: Edward Warnicke <hagbard@...> Date: Tuesday, March 31, 2015 at 7:05 AM To: Reinaldo Penno <rapenno@...> Cc: "controller-dev@..." <controller-dev@...>, "ovsdb-dev@..." <ovsdb-dev@...> Subject: Re: [controller-dev] OVSDB, SFC and clustering Reinaldo, I believe that persistence is only turned on for the config data store, not the operational datastore, so on reboot, operational data would be refreshed. Ed On Mon, Mar 30, 2015 at 8:50 PM, Reinaldo Penno <rapenno@...> wrote:
|