Hi there! I came across this repository and I believe this can in theory, provide a gRPC "dial-out" (call-home) mechanism for the devices (routers/optical elements) to call-home the collector similar use-case as NETCONF call home (Update: Indeed the use-case is dial-out as indicated by @robshakir here.)
Reading through the spec (link), a few things are not very clear. It would be great if the spec can be updated to add some more clarity:
The reference to "tunnel server" and "tunnel client" throughout the document, are these separate entities other than the client/collector and the device/server? (I mean, a client and a server in the classic sense)
I can envisage a separate trusted man-in-the-middle "tunnel server" that can patch the connections between the clients and the server. Not sure if this is intention?
Would it be possible to provide a figure that explains the workflow? A simple example would be good enough
The initial figure uses "gRPC Client" and "gRPC Sever"; However, the next figure uses "tunnel client" and "tunnel server"
Would it be possible to add annotations depicting order of events in the timing diagram here?
Also in this figure, do the "server" and "client" refer to the typical device and collector respectively?
Also, is this project something that the OpenConfig group considers "official" and perhaps a way to support gNMI dial-out?
Hi there! I came across this repository and I believe this can in theory, provide a gRPC "dial-out" (call-home) mechanism for the devices (routers/optical elements) to call-home the collector similar use-case as NETCONF call home (Update: Indeed the use-case is dial-out as indicated by @robshakir here.)
Reading through the spec (link), a few things are not very clear. It would be great if the spec can be updated to add some more clarity:
Also, is this project something that the OpenConfig group considers "official" and perhaps a way to support gNMI dial-out?