Operating System: All
Platform: All

For Li-design the barrier flag by flow, group and meter is ignored because you can wait in the invoking code for the future result or particular rpc. Or you can hook a callback or chain another future using Futures.transform(..).

Anyway there is service designed for explicit barrier sending:

(you need rpcBroker in order to get the service proxy and instanceIdentifier of target device node)

final FlowCapableTransactionService barrierService =
getRpcRegistryDependency().getRpcService(FlowCapableTransactionService.class);

final SendBarrierInput barrierInput = new SendBarrierInputBuilder()
.setNode(new NodeRef(nodeInstanceIdentifier)).build();

final Future<RpcResult<Void>> rpcResultFuture =
barrierService.sendBarrier(barrierInput);

Now again you need to wait for result as this call is asynchronous too.

(In reply to michal rehak from comment #1)
> For Li-design the barrier flag by flow, group and meter is ignored because
> you can wait in the invoking code for the future result or particular rpc.
> Or you can hook a callback or chain another future using
> Futures.transform(..).

We've also confirmed that the OpenFlow Plugin Li design ignores the barrier flag in the input for add-flow RPC and remove-flow RPC.

I think this is a bug, so should be fixed. The OpenFlow Plugin Lithium design should not ignore the barrier flag, since there is no reason to ignore the flag. When an application asks the plugin to send a BARRIER_REQUEST, the plugin should send the BARRIER_REQUEST immediately after a FLOW_MOD.

I think waiting for the future result or hooking a callback is not related to the problem here.

Hi Hideyuki,
in He-design rpc futures get completed upon message sent by netty.
In Li-design rpc futures get completed when:

• corresponding error arrives
• or reply (if protocol defines it)
• or upon subsequent barrier reply (barrier request was sent after the rpc message)

Of course it takes more time for rpc in Li to complete. But the result contains all the relevant info and app can rely in that.

Appending an explicit barrier to flow/meter/group will cause that completion might happen earlier (up to 500ms). Otherwise there is always an automatic barrier sent in order to flush all outstanding rpcs. This automatic barrier is optimized so that it is not being sent too often.

In nutshell: if you need to be sure that previous flow is installed on device you either need to wait for subsequent barrier reply or wait for statistics. I understand that in He-design the future from rpc gets completed very fast. But on app side it is not possible to control. Attaching barrier in He-design is the only way how to be sure that device processing is completed.
In Li-design this is done by design and if you need explicit barrier in order to speed up a bit even by taking the risk of flooding device with barriers then you can do so by invoking appropriate rpc. All you need to do is to invoke barrier rpc in the same thread in which you invoked the previous rpc.

(In reply to michal rehak from comment #3)
> Hi Hideyuki,
> in He-design rpc futures get completed upon message sent by netty.
> In Li-design rpc futures get completed when:
> - corresponding error arrives
> - or reply (if protocol defines it)
> - or upon subsequent barrier reply (barrier request was sent after the rpc
> message)
>
> Of course it takes more time for rpc in Li to complete. But the result
> contains all the relevant info and app can rely in that.
>
> Appending an explicit barrier to flow/meter/group will cause that completion
> might happen earlier (up to 500ms). Otherwise there is always an automatic
> barrier sent in order to flush all outstanding rpcs. This automatic barrier
> is optimized so that it is not being sent too often.
>
> In nutshell: if you need to be sure that previous flow is installed on
> device you either need to wait for subsequent barrier reply or wait for
> statistics. I understand that in He-design the future from rpc gets
> completed very fast. But on app side it is not possible to control.
> Attaching barrier in He-design is the only way how to be sure that device
> processing is completed.
> In Li-design this is done by design and if you need explicit barrier in
> order to speed up a bit even by taking the risk of flooding device with
> barriers then you can do so by invoking appropriate rpc. All you need to do
> is to invoke barrier rpc in the same thread in which you invoked the
> previous rpc.

Hi Michal,

Thank you for your comment!

My understanding about "when RPC futures get completed" in the Li-design and He-Design is the same with what you explained here.

So do you suggest VTN Project should use the send-barrier RPC modeled in flow-capable-transaction.yang in the Li-design in Boron?
If the OFP project continuously supports the send-barrier RPC in Boron, it would work fine for the VTN project.

I've asked about this to the OFP project folks in the ML in March, but I've not received any responses about it yet.
https://lists.opendaylight.org/pipermail/openflowplugin-dev/2016-March/004808.html

Barrier API (flow-capable-transaction.yang) shall stay with us at least till Carbon. And currently there is no plan to deprecate it.

VTN blocked by this.

Not a blocking issue for VTN any longer - as VTN has already implemented calling the send barrier RPC.

No longer critical