openconfig/reference

Clarification: keyless list handling

Closed this issue · 1 comments

Looking for guidelines on handling keyless lists e.g.,
/network-instances/network-instance[name=vrfInst1]/protocols/protocol[identifier=BGP][name=bgp]/bgp/rib/attr-sets/attr-set[index=1]/as-path/as-segment. This list is defined without any keys. Below is a definition tree of the same. There are other occurrences as well.

...
        |        +--ro rib
        |           +--ro attr-sets
        |           |  +--ro attr-set* [index]
        |           |     +--ro index                                             -> ../state/index
        |           |     +--ro state
        |           |     |  +--ro index?              uint64
        |           |     +--ro as-path 
        |           |     |  +--ro as-segment* [] 
        |           |     |     +--ro state
        |           |     |        +--ro type?     oc-bgpt:as-path-segment-type
        |           |     |        +--ro member*   oc-inet:as-number
        |           |     +--ro as4-path
        |           |     |  +--ro as4-segment* []
        |           |     |     +--ro state
        |           |     |        +--ro type?     oc-bgpt:as-path-segment-type
        |           |     |        +--ro member*   oc-inet:as-number
...

Openconfig style-guide explicitly mention how to handle keyless list. However, I did not see any mention of atomic around such lists; this is in openconfig-rib-bgp-attributes and related yang files. Moreover, there is no clarity on how these are encoded as gnmi.Updates for a gnmi.Get/Subscribe, especially when such list contain more than one elements. As the key is absent, the resulting path for different instances will always be same !

Additionally, how a gnmi.Set should specify any values for such lists (assuming they exist in config path as well)? Will it be always going to be an overwrite operation for both Replace/Update cases ? If the list contains more than one instances, how are they to be specified?

When tried YGOT's TogNMINotifications , it results in an error as "unimplemented: keyless list cannot be output" as detailed in TogNMINotifications: Option to ignore unsupported fields

Does this mean such key-less lists cannot be encoded as gnmi.Notification's gnmi.Updates ?

Any clarifications/examples on this front will be helpful.

These two unkeyed lists have been converted to keyed lists.
See openconfig/public#750

YANG does not permit config true lists to be unkeyed, and for state data as you pointed out it or one of its parent nodes must be marked as telemetry-atomic as otherwise they would not be streamable due to the path issue.