Coverage extent of 'path' for Get/Subscribe request

[gsindigi]

Given the Openconfig data-model, are there any set guide-lines forpath variable to be used in gNMI Get or Subscribe requests ? Please note that, I am not looking for syntactical guidelines here, which are already specified with greater length of details; Instead, what am looking for is more to do with semantic coverage of given a path and how much the path's coverage should be ? Below questions are applicable to both Get & Subscribe requests.

1. For larger data sets, it is suggested to use Subscribe than Get, so that data can be streamed per section 3.5. Can a client specify a high-level path something like '/' (root) and expect all of the data tree to be streamed ? Such an operation can become quite resource intensive on the target, though it is streaming.
2. Similar question for SubscriptionRequest as well. Can a client subscribe for high-level path e.g., /network-instances/network-instance and expect to receive Updates per the request made, whenever any change happens in any of the sub-trees which could go upto multi-levels e.g., /network-instances/network-instance/protocols/protocol/bgp/... ? This could pose potential performance issues when it comes to tracking of highly scaled state information such as routes learnt of a particular network-instance. To add to this, such information can also be very dynamic in nature.

As a greedy/lazy gNMI client application, it might be easy to ask for everything by specifying a high-level path which covers a majority of the state data, but actually may be interested in very minor percent of such data. This could keep the gNMI server busy with tracking and publishing state information when the network is busy. So, in such cases, having rules to limit the data coverage or forcing to ask specific/explicit sub-set of information will help keep things under control.

[robshakir]

Hi!

Data volume is clearly a consideration that is needed for any streaming application -- however, what information is required from a target is clearly dependent upon the system that is being implemented around it. As such, there could be applications that absolutely need the contents of subscribing to /. Equally, gNMI is not tightly coupled to OpenConfig as a data model (which I think is an implicit assumption in your question). Given that this is the case, it's not clear that some generic guidance can be made here.

In addition to this lack of guidance, it's not clear that there's a common scaling number that could be used for all target implementations -- for example, there are implementations that can scale to a high update rate for /.

The target has a few means to be able to limit the data volume that it is going to transmit:

• It can not support a particular sample_interval for paths which it cannot service at that rate.
• It can support ON_CHANGE subscriptions to ensure that it does not need to try and scale to send large amounts of redundant periodically streamed data.
• It can support TARGET_DEFINED with a sample_interval of 0 which gives it control over the rate that it sends data at for a subscription.

I'm not against thinking about these considerations - and seeing whether there are application notes that we can write that relate to OpenConfig schemas via gNMI (e.g., /network-instances/network-instance/afts likely should be an ON_CHANGE implementation primarily, /network-instances/network-instance/protocols/protocol/bgp/rib should be ON_CHANGE and even consider the on the wire encoding to be scalable to Internet DFZ table sizes), but I don't think this can be done generically.

Do you disagree?

Cheers, r.

[gsindigi]

Thanks Rob for your response. While, it may not be possible to have generic guidelines, I think its going to keep the network element busy inspite of having supported the 3 alternatives you suggested. And, it not necessarily with OpenConfig data models alone as gNMI is generic and can be used with other models as well. The kind of scale with BGP/rib as you rightly pointed an e.g., DFZ table sizes can be challenging to support especially if gNMI support going to be built around legacy set of protocol daemons. This might as well applicable to both data-store (state info repository) and frequent retrievals (from respective protocols) and on-wire encoding. Are there any reference metrics with respect to scale vs resources utilization e.g., cpu, memory, network-bandwidth etc and gNMI server requirements to support such? What am I trying to see is to have some checks/precautionary measure in place so that regular core functionality of the network element is intact and still support gNMI with possible scale; I understand, this is totally contextual and vary depending on applications.

-GS.

[robshakir]

I'm just not sure that one can write these down -- there are multiple implementations that support gNMI today, and looking across them, I see little commonality in the architecture that has been chosen to implement them.

Equally, a lot of the update rate depends on the network that the element is deployed in. Whilst it might be possible to write some empirical observations of existing implementations in some networks, I'm not sure that there's something generic here.

r.

[gsindigi]

@robshakir The issue#97 I'd raised was with respect to have a server side validations of the paths requested to a gNMI server before further processing. The idea was to leverage the YANG schema, (yang.Entry).Find("/given/path/to/any/gRPC/...") and see whether that particular module is being supported or not. In addition, use the (yang.Entry).Modules() information for request processing by a particular module provider/implementation;

As the issue seen was in GoYang modules, I thought it may be more appropriate to raise in that community, then based on your response, I resorted to clarify it here in the context of gNMI, which is driving us to look for these APIs. Hence clarifying it here.

Thanks G.