gNMI and path with both origin and YANG namespaces

[fperrin]

Hi @akarneliuk ,

I need to generate paths that have both an origin, and a YANG namespace in the top-level element (and in fact, in subsequent elements too). Those paths look like the second example in https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/prog/configuration/1610/b_1610_programmability_cg/gnmi_protocol.html#id_84819:

path {
  origin: "rfc7951"
  elem {
    name: "openconfig-interface:interfaces"
  }
  elem {
    name: "interface"
    key {
      key: "name"
      value: "Loopback111"
    }
  }
}

The current code in pygnmi can't generate the path above, due to the way it parses path elements that contain :.

Unfortunately, Schema path encoding conventions for gNMI doesn't specify how to encode the origin of the path. One possible way to do this is to look at the first path element only, and if that element contains a :, then set the origin from that. The XPATH for the path I quoted above would look like: rfc7951:openconfig-interfaces:interfaces/interface[name=Loopback111], or (maybe more explicit): rfc7951:/openconfig-interfaces:interfaces/interface[name=Loopback111]. I have some code that does just that, see the draft PR #41 I'm opening at the same time. The problem with that approach is that this doesn't quite conform to XPATH specification.

Another possible way is to add an extra optional argument to get, subscribe, etc., that specifies the origin. If that argument is unset, then guess the origin from the XPATH (ie. current behaviour). If that argument is set, then it is used for the gNMI path, and : in the path elements is not treated specially. Ie. to get the path I quoted above, you would have to call gnmi_path_generator("/openconfig-interfaces:interfaces/interface[name=Loopback111]", origin="rfc7951"). The downside of this approach is that it requires more changes and the API becomes a bit more complex. I haven't tried to write that approach yet Draft of that second approach: https://github.com/fperrin/pygnmi/commits/fp-gnmi-path-origin

What do you think?

[akarneliuk]

Hello @fperrin ,

sorry, was extremely busy past 3 weeks and really didn't have time to look into that earlier. What you say is an interesting point. So we build the origin as we build in accordance to gNMI specification: https://github.com/openconfig/reference/blob/master/rpc/gnmi/mixed-schema.md

I'm a little bit uneasy about adding extra arguments, as the idea to keep pygnmi as simple and as close the gNMI specification as possible. Moreover, I've read the mentioned RFC 7951 (https://datatracker.ietf.org/doc/html/rfc7951), and I don't see there any mentioning about origin at all.

having said that, is there a problem to use pygnmi with Cisco IOS as it requires the module name to be the top level key? If yes, would it mean that in all the path for Cisco IOS we need to include the module? If that is the case, probably, we can thing to add a variable to gNMIclient, which could be rfc7951 and which then alters the gnmi_path_genetator, as you explained in the second case.

Best, Anton

[fperrin]

Hi @akarneliuk ,

Point taken about adding extra arguments, I'll not use that approach.

I'm using pygnmi with a device (that's not released yet) that expects paths of the form described there (ie. I'm quoting that Cisco document because the device I'm using has paths of the same format, not because I'm using a Cisco device) :

https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/prog/configuration/1610/b_1610_programmability_cg/gnmi_protocol.html#id_84819 An RFC 7951-specified namespace prefixing also uses the YANG module name. For example, the openconfig path to a loopback interface will be /openconfig-interfaces:interfaces/interface[name=Loopback111]/

The following example shows a gNMI path with RFC7951 namespacing:

path {
origin: "rfc7951"
elem {
name: "openconfig-interface:interfaces"
}
elem {
name: "interface"
key {
key: "name"
value: "Loopback111"
}
}
}

The important points are that there is a non-default origin, and some of the path elements still have : in the name. In fact, elements besides the first one can have : in the name.

The more I think about it, the more I think this all means we can get away with a very simple change: only treat : specially in the first element to set the origin, and ignore it otherwise. I'll give that a go and update #41 accordingly.

That'd mean you can generate the path above from the string rfc7951:openconfig-interfaces:interfaces/interface[name=Loopback111].

I'm not sure about the extra variable to gNMIclient, because then it means all requests will have to use the same origin, and the document you linked hints at devices that have different parts of their tree addressed differently (I do not know of devices that require that, I certainly don't have devices that require that, but it's a possibility).

[fperrin]

Thanks for the merge of #41 , @akarneliuk. For my purpose, it is enough, and allows to specify the paths I need, including the examples in tests/ I included.