Feature Request: Support RFC 6022 (NETCONF Monitoring)

[pheller]

Whereas the YANG Module Library does include an optional leaf (named "schema") of type inet:uri where one may retrieve the YANG module in question, RFC 6022 provides an additional NETCONF RPC ("get-schema") that enables a NETCONF client to directly retrieve from a device the YANG modules that it has implemented.

[olofhagsand]

Capability and schema support (including get-schema RPC) will be a first step Datastores, sessions and statistics a second.

[olofhagsand]

Questions to @pheller: 1) Whether to have a configuration option for netconf monitoring or not? On the one hand RFC6022 is a basic functionality, on the other hand, it brings a lot of extra state data. 2) There is a location parameter in the schema state which (parat from NETCONF/get-schema retrieval) only makes sense in a product using clixon, eg an HTTP url. Should this be configurable in some way?

[pheller]

Certainly the location "NETCONF" needs to be returned to enable clients to retrieve the active schemas that CLIXON has loaded.

As to whether CLIXON might expose the schemas in some other way; via the native restconf server, for example, should probably be a configurable option.

[olofhagsand]

Two new config options introduced, eg:

<CLICON_NETCONF_MONITORING>true</CLICON_NETCONF_MONITORING>
<CLICON_NETCONF_MONITORING_LOCATION>https://localhost/www</CLICON_NETCONF_MONITORING_LOCATION>

[olofhagsand]

Discussion of capabilities exchange for netconf-monitoring. RFC6241 mentions:

The device uses capabilities to announce the set of data models that the device implements.

whereas RFC7950 says:

A server advertises support for YANG 1.1 modules by using ietf-yang-library [RFC7895] instead of listing them as capabilities in the <hello> message.

Since then RFC7895 has been replaced by RFC 8525.

Therefore Clixon uses ietf-yang-library RFC8525 to announce it provides "urn:ietf:params:xml:ns:yang:ietf-netconf-monitoring".

But there may be implementations of controllers/orchestrators that may still rely on modules being announced via the protocol. But I am unaware of this. Are there such implementations?

[pheller]

At least one product I have tried first tries RFC7895, and failing that, accepts the module list within the hello-exchanged capabilities as defined in RFC 6020.

The configuration specifics that allowed the product to work was:

  <CLICON_YANG_LIBRARY>true</CLICON_YANG_LIBRARY>
  <CLICON_MODULE_LIBRARY_RFC7895>true</CLICON_MODULE_LIBRARY_RFC7895>

[pheller]

With the commit https://github.com/clicon/clixon/commit/a38c54e4ccfa26ebc53617bfff6b421df66c6c5e I believe the schema related pieces from RFC6022 are functional.

[pheller]

Incidentally, with the above configuration, the MG-SOFT NETCONF Browser errors like so:

[2022/12/04 20:17:36] Session 0ea3d333-e6b1-43fc-9a2f-3f7531855cd4 message:
[2022/12/04 20:17:36] Session 0ea3d333-e6b1-43fc-9a2f-3f7531855cd4 got a suspicious hello message from localhost. Server advertised YANG Library capability 1.0, yet its revision parameter lists 2019-01-04 (YANG Library 1.1).
[2022/12/04 20:17:36] 
[2022/12/04 20:17:36] Session 0ea3d333-e6b1-43fc-9a2f-3f7531855cd4 message: rpc sent.
[2022/12/04 20:17:36] 
[2022/12/04 20:17:36] Session 0ea3d333-e6b1-43fc-9a2f-3f7531855cd4 message: reply received.
[2022/12/04 20:17:36] 
[2022/12/04 20:17:36] Failed to obtain YANG library information: invalid YANG Library detected (unknown yang library version (0)).

The specific complaint invalid YANG Library detected (unknown yang library version (0)). is due to this RPC:

<rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="2">
  <get>
    <filter>
      <yanglib:yang-library xmlns:yanglib="urn:ietf:params:xml:ns:yang:ietf-yang-library"/>
    </filter>
  </get>
</rpc>

Receiving this response:

<?xml version="1.0" encoding="utf-8"?>
<rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="2">
  <data/>
</rpc-reply>

... leading to could not parse server's YANG library

[olofhagsand]

The session part of RFC 6022 netconf-state is now implemented. Some comments:

• the "transport" identity has been extended from the RFC in clixon-lib.yang with: "netconf", "snmp", "cli" and "restconf". The original just had netconf-ssh which was applicable, but clixon-backend does now know whether the session is over SSH or not.
• the "source-host" is mostly not usable in clixon, since, again, the backend has problems knowing where the session origins for the same reasons as the previous. Further, for restconf sessions, many original http sessions are multiplexed on a single, this being especially so for the reverse proxy/nginx restconf mode.

[olofhagsand]

With https://github.com/clicon/clixon/commit/6681eb99d3e1425aef91ac9c170d57ea4fbfd397 this should now be completed. Please verify