This bug is triggered similarly to CONTROLLER-541.

This may be bug of BGPCEP plugin, but I guess RPC input data validation is a job for restconf component.

Bug was encountered when using ODL configured to use draft-ietf-pce-stateful-pce-02 extension to PCEP in environment with capable PCCs, I do not know how to replicate bug without them.

As a preparation, add-lsp has to be called, here is example curl number 1:
curl -X POST -H "Content-Type:application/yang.data+json" -d '{"input":{"node":"pcc://39.39.39.39","name":"my_name","network-topology-ref":"/network-topology:network-topology/network-topology:topology[network-topology:topology-id=\"pcep-topology\"]","arguments":{"endpoints-obj":{"ipv4":

}}}}' 127.0.0.1:8080/restconf/operations/network-topology-pcep:add-lsp

Critical step happens when calling update-lsp without "ero" field. Example (verbose) curl number 4:
curl -v -X POST -H "Content-Type:application/yang.data+json" -d '{"input":{"node":"pcc://39.39.39.39","name":"my_name","network-topology-ref":"/network-topology:network-topology/network-topology:topology[network-topology:topology-id=\"pcep-topology\"]","arguments":

}}' 127.0.0.1:8080/restconf/operations/network-topology-pcep:update-lsp

This call produces no lines in opendaylight.log (default logback.xml except org.opendaylight.bgpcep set to TRACE), curl does not print any response related text and just keeps waiting indefinitely.

For comparison, here is correct form of intended update-lsp, as example curl number 3:
curl -X POST -H "Content-Type:application/yang.data+json" -d '{"input":{"node":"pcc://39.39.39.39","name":"my_name","network-topology-ref":"/network-topology:network-topology/network-topology:topology[network-topology:topology-id=\"pcep-topology\"]","arguments":{"operational":true,"ero":[{"subobject":{"loose":false,"ip-prefix":

}},{"subobject":{"loose":false,"ip-prefix":

}},{"subobject":{"loose":false,"ip-prefix":

}}]}}}' 127.0.0.1:8080/restconf/operations/network-topology-pcep:update-lsp

And to get back to initial state (before curl number 1) it seem to be sufficient to just call remove-lsp, using example curl number 0:
curl -X POST -H "Content-Type:application/yang.data+json" -d '{"input":{"node":"pcc://39.39.39.39","name":"my_name","network-topology-ref":"/network-topology:network-topology/network-topology:topology[network-topology:topology-id=\"pcep-topology\"]"}}' 127.0.0.1:8080/restconf/operations/network-topology-pcep:remove-lsp

What is wrong? Lack of response. For differently malformed RPCs I have seen error code 400 with helpful message, so I expected the same here.