On a previous patch [1] it was proposed on a scenario where the origin and destination where on the same node, an egress classifier function would de-encapsulate the traffic and inject back on it's normal course as this was something much more difficult to achieve for SFC on its own.

In the case where the last SF is on a different node, the SFC will send the encapsulated packet on egress to the ip address included in NSH C1 metadata.

To be able to handle this traffic, the egress classification function needs to be registered as a terminating service action for SFC traffic (VNI=0). the problem is that SFC itself might be registered as such as well, and the terminating service action API provided by genius does not offer to handle different priorities on this case. This would not be a problem if service binding had been used for tunnel ports also, which is still not the case currently.

As a temporary workaround, the egress classification service should install a flow on the internal tunnel table (36) to take SFC traffic to its pipeline, with higher priority than the SFC terminating service action. The the egress classification function, based on the final NSI of each path, will determine if it should apply the chain egress function. If it is not the case, it should handoff the traffic bSFC pipeline.

A more elaborated workaround would be to use a specific VNI value at chain egress but currently it is not clear what possible VNI values are free for use.

[1] https://git.opendaylight.org/gerrit/#/c/60764/