Question: SubscriptionList/Subscribe in line with GetRequest

[gsindigi]

In GetRequest, the gNMI client has the flexibility to choose the kind of data to be served by target by using different options as described The GetRequest Message section especially DataType and Encoding options. Likewise, should either of SubscriptionList/Subscribe message too have similar options to choose from? That way, both Get and Subscribe RPCs would be consistent with respect to the options to choose from. Many a times, it will be required by a client to pull only config or state data alone, rather than a combination of both. Without these parameters, the client may need to make multiple Subscribe requests to receive only a certain type of data e.g., config by having it in the path attributes.

[wenovus]

Subscribe has an Encoding field: https://github.com/openconfig/gnmi/blob/master/proto/gnmi/gnmi.proto#L279

@robshakir Any previous discussions to introduce

  enum DataType {
    ALL = 0;                            // All data elements.
    CONFIG = 1;                         // Config (rw) only elements.
    STATE = 2;                          // State (ro) only elements.
    // Data elements marked in the schema as operational. This refers to data
    // elements whose value relates to the state of processes or interactions
    // running on the device.
    OPERATIONAL = 3;
  }

to Subscribe?

[robshakir]

//cc @gcsl

There hasn't been such a request that I am aware of. I'm not sure that I am supportive of adding this.

The reason that we added this in a GetRequest was because there is a significant amount of data that needs to be compiled together when a Get is issued to give a single response to the client. If this were required to include all telemetry information as well as configuration - for example - then we are likely to see OOMs. A very common use case for Get is simply to retrieve the current running configuration.

With Subscribe we don't have such resource constraints on the device (it can stream all leaves individually as the spec discusses), such that the same consideration of pushing functionality onto the device adds more complexity. There are a couple of other considerations too:

• it is already possible to do queries like .../config or .../state in the path conventions. For OpenConfig models, this means that there is already some way to handle this kind of query.
• for telemetry, we know there will be schema-unaware collectors (whereas for Get, clients generally need to be able the unmarshal the structured data that comes back, they are much more likely to be schema-aware in all the use cases I've heard from) - having base support for filtering based on schema attributes would not be supportable by such collectors (they have no idea of such metadata).
• if we were to add this, given the number of implementations, and the fact that this hasn't come up before - a gNMI extension would likely be a reasonable approach.

[hellt]

@robshakir We had the same request raised internally many times, the prime use case was with Network Management Systems being in need of subscribing only to config leaves to track configuration drift. We ended up implementing a bunch of custom encodings that deliver that kind of functionality.

I share the sentiment of having this is a registered extension, if not being part of the spec.

[gsindigi]

• it is already possible to do queries like .../config or .../state in the path conventions. For OpenConfig models, this means that there is already some way to handle this kind of query.

Yes, though it's possible to query requisite config/state attributes, it requires to form such paths explicitly and make a Subscribe request. E.g., For interfaces related config attributes, this could translate to below paths for an OpenconfigInterface module /interfaces/interface/config /interfaces/interface/subinterfaces/subinterface/config /interfaces/interface/ethernet/config /interfaces/interface/aggregation/config .... From an NMS standpoint, it's typical of retrieving any of config or state or both types of attributes based on the different scenarios. Say for a config drift resolution, config only is sufficient. This could potentially add more paths to Subscribe request. When there are more such paths to handle, one would easily fall back to option of retrieving at a higher level say /interfaces/interface and ignore the unwanted blocks. Or use multiple Gets as the target allows!

Either as the part of spec or as a registered extension, this could be very useful feature to use from NMS' perspective. Additionally, from device standpoint, it will ease the processing if you know a priori the type of data to deal with. However, this need not be the guiding factor.