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

Clarification: keyless list handling #166

Closed gsindigi closed 1 year ago

gsindigi commented 2 years ago

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.

wenovus commented 1 year ago

These two unkeyed lists have been converted to keyed lists. See https://github.com/openconfig/public/pull/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.