Add yang-version 1.1 to netconf capability

NETCONF
1

Hi,
Recently we moved to yang version 1.1 and noticed that corresponding yang namespaces are not exported in NETCONF capability message (in confd-6.7.3 version).

We have enabled both versions in confd.conf

  <netconf>
    <enabled>true</enabled>
    <versions>
      <v1.0>true</v1.0>
      <v1.1>true</v1.1>
    </versions>
...

We are loading following netconf fxs

# ls -l fxs/*netconf*
-rw-r--r-- 1 root root 5853 Jul 11 11:01 fxs/ietf-netconf-acm.fxs
-rw-r--r-- 1 root root 9731 Jul 11 11:01 fxs/ietf-netconf-monitoring.fxs
-rw-r--r-- 1 root root 6478 Jul 11 11:01 fxs/ietf-netconf-notifications.fxs
-rw-r--r-- 1 root root 5052 Jul 11 11:01 fxs/tailf-netconf-monitoring.fxs

Is anything else to be done to support yang-version 1.1 in capability message.

2

hello,
what specifically do you mean by “capability message”, can you give an example of actual result and what is the expected difference?

Do you refer to complied modules capabilities advertised by ConfD on <hello> exchange?
If the yang modules were compiled and loaded to ConfD as 1.0 modules, i assume they will not show up “by itself” as 1.1 with only NETCONF 1.1. enabled, but modules being left in original state as 1.0 ones…

3

@josephm yes I was talking about the module capabilities advertised in <hello> message.

Let me explain our setup in little detail.

  • Initially our yangs were all yang-version 1.0 And they were all advertised in the capability message of the form
<?xml version="1.0" encoding="UTF-8"?>
<hello xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<capabilities>
<capability>urn:ietf:params:netconf:base:1.0</capability>
<capability>urn:ietf:params:netconf:base:1.1</capability>
<capability>urn:ietf:params:netconf:capability:writable-running:1.0</capability>
<capability>urn:ietf:params:netconf:capability:xpath:1.0</capability>
<capability>urn:ietf:params:netconf:capability:validate:1.0</capability>
<capability>urn:ietf:params:netconf:capability:validate:1.1</capability>
<capability>urn:ietf:params:netconf:capability:rollback-on-error:1.0</capability>
<capability>urn:ietf:params:netconf:capability:notification:1.0</capability>
<capability>urn:ietf:params:netconf:capability:with-defaults:1.0?basic-mode=trim&amp;also-supported=report-all-tagged</capability>
<capability>http://tail-f.com/ns/netconf/actions/1.0</capability>
<capability>http://tail-f.com/ns/netconf/extensions</capability>
<capability>http://tail-f.com/ns/netconf/query</capability>

....

<capability>http://www.cdot.in/ns/tunnel-te?module=tunnel-te&amp;revision=2018-01-03</capability>
...
<capability>http://www.cdot.in/ns/vrf?module=vrf&amp;revision=2017-06-05</capability>
....
</capabilities>
<session-id>101</session-id></hello>]]>]]>

  • Now some of the yangs were converted to 1.1 i.e. (yang-version 1.1 statement was added in the yang file) as we needed some 1.1 yang features (identities / actions etc). There was no change in confdc arguments to compile these new yangs.

  • The mixture of fxs files (some 1.0 and some 1.1) are delivered and loaded to confd.
    We load fxs simply by providing loadPath variable in confd.conf

<loadPath>
    <dir>./fxs</dir>
</loadPath>

( You mentioned ‘loaded as 1.0’ . Is it controllable by some confd.conf settings?)

My assumption was with this setup, confd hello capability message would include both 1.0 and 1.1 yang modules, which is not happening. Confd only generates 1.0 module capabilities.

So I would like to know whether this is a known behavior of confd or I have missed some settings (as a workaround in this case, I can always publish 1.1 modules as custom capabilities in confd.conf file)

4

The list of YANG 1.1 modules are available using YANG Library (RFC 8525). YANG 1.1 (RFC 7950) says:

The following changes have been done to the NETCONF mapping:
o A server advertises support for YANG 1.1 modules by using
ietf-yang-library [RFC7895] instead of listing them as
capabilities in the message.

5

sorry, i used not that great phrasing - what i meant was YANGs built into fxs exactly like you mention in your detailed description at compile time - via presence/absence of yang-version statement…

As Greg mentions, try checking the list of modules via netconf get message and corresponding ietf-yang-library path…

6

@greg / @josephm ,
Thanks for pointing towards the standard method of sharing the module information. However I don’t seem to get it working

An GET with following

<get>
     <filter type="subtree">
           <yang-library xmlns="urn:ietf:params:xml:ns:yang:ietf-yang-library">
           </yang-library>
     </filter>
</get>

gets me empty data

<?xml version="1.0" encoding="UTF-8"?>
<rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="urn:uuid:7855cdb5-52c5-4504-81f1-ff0cc62d28f2" xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0">
    <data>
    </data>
</rpc-reply>

Do I need to load any other module (together with ietf-yang-library.fxs)

7

Try something like:

$ netconf-console --get --subtree-filter=-<<<'<modules-state xmlns="urn:ietf:params:xml:ns:yang:ietf-yang-library"/>'

I.e.

    <filter type="subtree">
      <modules-state xmlns="urn:ietf:params:xml:ns:yang:ietf-yang-library"/>
    </filter>

See RFC 7950 - The YANG 1.1 Data Modeling Language and RFC 7895 - YANG Module Library for details.

1 Like
8

That does it. Thanks.

My google-foo led me to RFC 8525 - YANG Library which defines a top-level container named yang-library

module: ietf-yang-library
     +--ro yang-library
        +--ro module-set* [name]
        |  +--ro name

For the sake of completeness, RFC8525 seems to replace RFC 7895. So would the newer version of confd implement the new RFC?

9

i have no information about planned roadmap so cannot answer this, but RFC 8525 is from 2019, which is imho “way too recent” in the networking standards terms to have been already implemented :slight_smile:

10

RFC 8525 is supported by ConfD, so a subtree filter for /yang-library works too.

netconf-console --get --subtree-filter=-<<<'<yang-library xmlns="urn:ietf:params:xml:ns:yang:ietf-yang-library"/>'

 <filter type="subtree">
   <yang-library xmlns="urn:ietf:params:xml:ns:yang:ietf-yang-library"/>
 </filter>
1 Like