Re: [controller-dev] OVSDB, SFC and clustering


Reinaldo Penno <rapenno@...>
 

BTW,


"* OVS Bridge is successfully written into OVSDB Config store, but it is not instantiated on corresponding OpenVSwitch instance yet"

From: Reinaldo Penno <rapenno@...>
Date: Tuesday, March 31, 2015 at 9:31 AM
To: Edward Warnicke <hagbard@...>
Cc: "controller-dev@..." <controller-dev@...>, "ovsdb-dev@..." <ovsdb-dev@...>
Subject: Re: [controller-dev] OVSDB, SFC and clustering

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:
I’m facing some problems with clustering in SFC and stumbled on an issue with OVSDB

The access pattern is the following:

  • OpenvSwitch connects to ODL
  • OVSDB creates data in config datastore
  • SouthBound OVDSDB creates data in operational datastore
  • SFC listens to OVSDB operational store changes
  • SFC creates corresponding switch in SFC
Now let’s add clustering to the mix.

If ODL reboots:

  • OVSDB and SFC will have data for a switch that does not exist (yet) until it connects
  • Now, let’s suppose the OVS switch never reconnects. What then?

Will OVSDB keep this stale data around? How long will it wait until the switch reconnects?
If switch reconnects, will data in the OVSDB operational datastore be overwritten? One could assume switch configuration changed between ODL reboots.

All this is unclear to me and have profound impacts on how SFC works. 

Thanks,

Reinaldo







_______________________________________________
controller-dev mailing list
controller-dev@...
https://lists.opendaylight.org/mailman/listinfo/controller-dev


Join z.archive.ovsdb-dev@lists.opendaylight.org to automatically receive all group messages.