An opes services usage question

Alex, from prior e-mails we agreed the use case I described fits within the opes framework (basically we agreed on items 1, 2 and 3 but not item 4 in my last e-mail). I am now trying to resolve item 4, I have been looking over the last couple of e-mails and the current discussions around item 4 can be summarized around four potential suggestions to the "flow participant discovery" problem for the use case.

A) Tracing -  My conclusion of this discussion is that tracing is not a general purpose solution that will work with all application protocols (I am assuming that application protocol refers to any protocol enveloped by TCP or UDP). The comment that "each application protocol needs its own tracing profile and some 
application protocols will not be able to support embedded tracing at all." is very significant. I find it unrealistic to expect all application protocols (or even a significant number in common use today) will support embedded tracing any time soon. Also, it seems using tracing would be "overkill" for this problem.

B) HTTP Metadata -  While HTTP flows support the in-band transfer of small amounts of metadata this may not practical. The size and volume of the metadata could be too much for HTTP. Also, this does not provide a complete answer because HTTP is not the only application protocol we might have to consider.  This suggestion does not seem to be the best general purpose approach.

C) OCP -  OCP can't handle any proxy to proxy exchanges because there are no OCP profiles for proxy to proxy flows.

D) Load Balancer changes - Load balancers are usually high performance boxes and anyone building a load balancer would most likely object to adding additional processing to deal with "address translations". It seems impractical and risky to require the addition of new code into load balancers to support opes (even if it is only to append and replace IP addresses). Also load balancers will not be balancing metadata if the metadata is targeted to return to a particular proxy. Sending metadata through a load balancer will likely bring about scaling issues. All that is required to transfer the metadata, in this case, is simple out of band communication (once the correct address is  known).

All this discussion bring me back to where I started with my initial opes e-mail. It is apparent that a practical opes solution, useful today, is not available for this use case. I recognize that the opes framework is not complete. But I would really like to see the framework extended to handle this services use case, which I believe will become one of the first opes deployments.  I continue to believe that the opes framework is the best way to solve this services usage problem and maintain an open system. I think this is what opes is all about.

Shouldn't we now look into how to extend the opes framework to satisfy the need for a "flow participant discovery" solution?  Solving the flow participant discovery  problem in the most general way without dependencies on load balancers opens up lots of ways of sending any metadata out-of-band between proxies. Your thoughts are greatly appreciated. Thanks again.
Regards  John