search

openconfig / reference

This repository contains reference implementations, specifications and tooling related to OpenConfig-based network management.
Apache License 2.0
155 stars 88 forks source link

Indexing unkeyed lists #76

Open aaronbee opened 6 years ago

aaronbee commented 6 years ago

We have a similar question to https://github.com/openconfig/reference/issues/66, but about unkeyed lists. How are paths to elements in an unkeyed list supposed to be represented in gNMI?

One convenient answer would be to outlaw unkeyed lists in OpenConfig models. My colleague did some research with grep and found just one unkeyed list in all the models. I opened an issue about that here https://github.com/openconfig/public/issues/94.

aaronbee commented 6 years ago

Sorry, I was wrong about there only being one instance of unkeyed lists in OpenConfig models. There are about a dozen.

robshakir commented 6 years ago

Hi Aaron,

Apologies, I missed this issue previously. Currently, we're proposing that for unkeyed lists, they are not referenced individually. For telemetry values, this means that they would need to be transmitted in an aggregate, such that the entire list is serialised. Equally, we've also been trying to reduce the number of unkeyed lists in the models to reduce this aggregation.

Do you see issues with this?

aaronbee commented 6 years ago

A problem I see is that every time any leaf changes we would need to check if that leaf's parent or its parent, etc. is an unkeyed list to be able to figure out if we should stream out just the leaf value or the whole unkeyed list. Though, the information about a leafs ancestors being an unkeyed list could be cached on the leaf, so that we only have to figure this out once per-leaf.

robshakir commented 6 years ago

That is true. An alternative would be to say that we add an implicit id key, which is used to reference a particular member of the list. The value of this could be defined by the target, and as long as it kept it consistent, then the collector would be able to keep the same index.

Since YANG lists can only be config false if they are unkeyed, then we'd ensure that we didn't end up with a case where the target generating the ID would mean that the client needs to have knowledge of how this was done.

This would mean that the same leaf semantics could be maintained as any other leaf. @gcsl, @aashaikh -- any thoughts?

aaronbee commented 6 years ago

We wouldn't be able to maintain consistency of the ID after a restart/crash of the OpenConfig process. Would that be a problem for you?

I'm more in favor of your first proposal. I assume we would be serializing the list as a JSON array. If ordering consistency is important we could sort the list members with some consistent algorithm.