Operating System: All
Platform: All

Waiting on Thomas Bachman, Keith and Paul Quinn for architecture

The title of this bug is incorrect. I spoke with Reinaldo Penno, and the intent is this:

when the state of a Service Function is changed (e.g. Data Plane Locator changes), it can cause a ripple of state changes in other objects (SFFs, RSPs, etc.). The intent of this bug is to verify that when a state change is made in an SF, that all the appropriate state propagations happen and are correct. There is no intent or expectation that OVSDB will be used to create bridges and tunnels on SFs (and in fact, it probably won't).

The title of this bug is incorrect. I spoke with Reinaldo Penno, and the intent is this:

when the state of a Service Function is changed (e.g. Data Plane Locator changes), it can cause a ripple of state changes in other objects (SFFs, RSPs, etc.). The intent of this bug is to verify that when a state change is made in an SF, that all the appropriate state propagations happen and are correct. There is no intent or expectation that OVSDB will be used to create bridges and tunnels on SFs (and in fact, it probably won't).

Ok so I tested this one and here is the result. I created a simple topology containing node, forwarder and one SF. SFC, SFP & RSP was also created. I used sfc dlux to do so.

Then I tried to change SF (SF type, DPL locator & transport type) and check configuration through postman. SFF dictionary has not been updated as well as SFC. RSP has been deleted, only SFP is still there, but it's not possible to create RSP anymore.

When we change only DPL locator & transport, RSP is deleted again, but is possible to create new one with existing SFP. SFF shows still the same old configuration.

What is the state in OVS? Did the Openflow rules change properly? Were they deleted when the RSP was deleted? This is what we need to explore.

moved to python

covered by GBP-166