robshakir
commented
7 years ago Hi Benoit,
[Congrats on issue #42 ;-), hopefully you know where your towel is]
We agree that this is something that gNMI should have (it is noted in the current specification as a TODO). There are a number of deployment cases whereby the target cannot actually be contacted by the client directly (e.g., it is behind NAT) and hence dial-out makes a lot of sense. It also seems that this approach would be a possible manner to mitigate scaling issues in the case that sending all Notification messages to a centralised entity in a system becomes a bottleneck. A linecard in such a system could dial out to the client if required.
My proposal is that we define a new service - for the reason that this would then be the specific stub that would be implemented at these dial-out clients. It should handle only Subscribe AFAICS, without any of the configuration manipulation RPCs - since it is not clear to me that such a use case is required at this point in time.
My proposal is therefore something like:
// gNMIDialOut defines a service which is used by a target system (typically a
// network element) to initiate connections to a client (collector). The server
// is implemented at the collector, such that the target can initiate connections
// to the collector, based on a configured set of telemetry subscriptions.
service gNMIDialOut {
// Publish allows the target to send telemetry updates (in the form of
// SubscribeResponse messaages, which have the same semantics as in the
// gNMI Subscribe RPC, to a client. The client may optionally return the
// PublishResponse message in response to the dial-out connection from the
// target. In this case, the client may modify the set of subscriptions
// that are to be published by the target by:
// - Specifying a client_id within the PublishResponse message. In this
// case the target should match pre-configured subscriptions the specified
// client_id, and send data only for the paths associated with the
// specified client_id.
// - Specifying a SubscribeRequest message within the subscriptions field of
// the PublishResponse message. This message has the same semantics as
// in the Subscribe gNMI RPC.
// In the case that the client specifies neither option, a default set of
// subscriptions (which should be configurable on the target) should be
// published to the client (collector).
//
// The configuration of subscriptions associated with the publish RPC may
// be through the OpenConfig telemetry configuration and operational state
// model:
// https://github.com/openconfig/public/blob/master/release/models/telemetry/openconfig-telemetry.yang
rpc Publish(stream SubscribeResponse) returns (stream PublishResponse);
}
// PublishResponse is the message sent within the Publish RPC of the gNMI
// dial-out service by the client (collector) to the target. It is used to
// modify the set of paths that are to be sent by the target to the collector.
message PublishResponse {
oneof request {
string client_id = 1; // A string identifying the client to the target.
SubscribeRequest subscriptions = 2; // Optional specification of the subscriptions.
}
}One thing we probably have to be careful about here is the terminology - since we probably want tor remain consistent with the rest of the gNMI specification.
How does this proposal sound? Happy to iterate on it, and try and add this to a future version of the gNMI spec. @gcsl, @hines, @aashaikh - any thoughts?
Cheers! r.
gcsl
marcushines-zz
pborman
melgendy-ciena
jipanyang
rodrigo-albuquerque
aashaikh
mpatrick02702
bitnovel
balajei
gNMI currently only supports dial-in (i.e. a client coming from the outside and connecting to the network element where the gRPC server implementing the gNMI spec listens), but we see a need for a dial-out streaming model as well.
Advantages of a dial-out approach:
This issue is about settling on a standard gRPC interface for gNMI dial-out streaming.
edit: issue #42! 🎉