Refine affected RSP search on SFF update 32/67432/3
authorJaime Caamaño Ruiz <[email protected]>
Mon, 22 Jan 2018 16:44:15 +0000 (17:44 +0100)
committerBrady Johnson <[email protected]>
Tue, 30 Jan 2018 22:29:50 +0000 (22:29 +0000)
commitf3ed46b2782020237b55928bb374e828265bb041
tree9f1f684666d9c0606caab1539b0e7c274f9d7953
parentb5cf90a1c35a89d0a5a9a47cb2750cf7c140325b
Refine affected RSP search on SFF update

Previously, any SFF locator update would cause the removal of any RSP
associated with that SFF. With this patch, in regards to a SFF locator
update, an associated RSP will be removed only if any of these
conditions are met:

* The SFF locator is used in a SF dictionary entry for an SF associated
with the RSP.

* The RSP is associated with more SFFs than the updated SFF so that the
updated locator could be used in a SFF-SFF hop.

This improvement is particularly meaningful for the logical SFF scenario
in combination with the changes introduced for the directional-dpl spec.
The logical SFF singleton is no longer an empty SFF and will be updated
frequently as paths are created or removed. It is fundamental that other
paths are not affected when they shouldn't.

The current data model does not allow for optimum processing and there
might be performance impacts on big SFFs, as the logical SFF most likely
will be. For a future release, there is the option to enhance the data
model to optimize this.

Change-Id: I16660e241779ff24bf644e4377e12965b12f695b
Signed-off-by: Jaime Caamaño Ruiz <[email protected]>
sfc-provider/src/main/java/org/opendaylight/sfc/provider/listeners/ServiceFunctionForwarderListener.java
sfc-provider/src/test/java/org/opendaylight/sfc/provider/listeners/ServiceFunctionForwarderListenerTest.java