[YANGTOOLS-1353] Yang models using "ietf-yang-schema-mount" mount-point are not supported in ODL Created: 19/Oct/21  Updated: 09/Feb/22

Status: Open
Project: yangtools
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Medium
Reporter: Robert Magaldi Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: File bbf-obbaa-network-manager@2021-02-01.yang     PNG File image-2022-02-01-09-34-47-260.png    

 Description   

The Broadband Forum has a YANG 1.1 model called bbf-obbaa-network-manager.yang model which uses a "root" yang-schema-mount. That is, the "root" can point to any other YANG model. 

Example: 

container network-manager {
        description
          "Infomations about the devices and adapters managed by BAA";
        container managed-devices {
            description
              "The managed devices and device communication settings.";
            list device {
                key "name";
                description
                    "The device list which managed by BAA.";
                leaf name {
                    type string;
                    description
                      "The name of device.";
                }
                container device-management {
                    description
                        "The management informations for a device.";
                    uses management-grouping;
                }
                container device-notification {
                    description
                        "The notification triggered when the device state changed.";
                    uses notification-grouping;
                }
                container root {
                    yangmnt:mount-point "root";
                    description
                      "Root for models supported per device.";
                }
            }
        }
       ...

In this yang model, there is a container called "root" which points to the root models of any yang model.  The "yangmnt" is:

 

import ietf-yang-schema-mount {
        prefix yangmnt;
    }

 

 

Usage of this can be seen in the following notification - A system may have a "netconf-config-change" notification for example that has this "network-manager" yang underneath it:

<notification xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0">
  <eventTime>2021-08-17T18:35:46+00:00</eventTime>
  <netconf-config-change xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-notifications">
    <datastore>running</datastore>
      <changed-by>
        <username>PMA_USER</username>
        <session-id>1</session-id>
        <source-host>172.16.0.2</source-host>
      </changed-by>
      <edit>
        <target xmlns:baa-network-manager="urn:bbf:yang:obbaa:network-manager"
              xmlns:bbf-xpongemtcont="urn:bbf:yang:bbf-xpongemtcont">/baa-network-manager:network-manager/baa-network-manager:managed-devices/baa-network-manager:device[baa-network-manager:name='myDevice']/baa-network-manager:root/bbf-xpongemtcont:xpongemtcont/bbf-xpongemtcont:tconts/bbf-xpongemtcont:tcont[bbf-xpongemtcont:name='tcont_ont1_2_0']</target>
        <operation>create</operation>
      </edit>
   </netconf-config-change>
</notification>

 

 Is we look at the "target" part of the message above, we see that it is using the network manager yang, and also the bbf-xpongemtcont...

/baa-network-manager:root/bbf-xpongemtcont:xpongemtcont/

The transition from "root" to an actual yang model (bbf-xpongemtcont) is not supported. ODL will throw away this notification because it cannot parse this.

In the following file:
yang/yang-data-util/src/main/java/org/opendaylight/yangtools/yang/data/util/XpathStringParsingPathArgumentBuilder.java  (yang tools 6.0.5)

  XpathStringParsingPathArgumentBuilder(final AbstractStringInstanceIdentifierCodec codec, final String data) {
        this.codec = requireNonNull(codec);
        this.data = requireNonNull(data);
        this.current = codec.getDataContextTree().getRoot(); // RSM This line
        this.offset = 0;
    }

 The "getDataContextTree" will be relative to the "bbf-obba-network-manager" yang when parsing. When it comes time to find the "bbf-xpongemtcont" model, it will return null causing the notification to be thrown away as it does not exist in the context tree.

Also, the yangtool issue here can be hacked to work allowing the notification up. But then there is a second issue where a notification listener for "netconf change notifications" will not get a proper JAVA object because of the "root schema mount". 

For example - 

org.opendaylight.mdsal.binding.dom.adapter.BindingDOMNotificationListenerAdapter

(mdsal-binding-dom-adaptor version 7.0.6)

@Override
public void onNotification(final DOMNotification notification) {
        final Notification baNotification = deserialize(notification);
        final QName notificationQName = notification.getType().lastNodeIdentifier();
        getInvoker(notification.getType()).invokeNotification(delegate, notificationQName, baNotification);
}

When the deserialize is complete, the baNotificaiton is not completely mapped to an object due to the "root" mount. 

More information can be added to this issue if required. Wondering if this is a known issue already related to YANG 1.1 and possibly part of 1.1 support in progress.

 



 Comments   
Comment by Robert Varga [ 25/Oct/21 ]

So YANG Schema Mount support is not thoroughly integrated in the stack, so depending on how the request is constructed, we may be losing some information we have.

A secondary problem here is that a schema mount can mean two different things. Can you post the contents of /ietf-yang-schema-mount:schema-mounts operational datastore?

Comment by Robert Magaldi [ 01/Feb/22 ]

Trying to clarify the issue...

I believe there are no contents for the /ietf-yang-schema-mount:schema-mounts operational data store. We are not storing anything in this case. 

I think the issue is more general - I have attached a file "bbf-obba-network-manager@2021-02-01.yang".  This is an Broadband forum network manager yang file which contains a "root" mount - meaning it points to any other yang model. 

Inside this yang for example there is this:

The issue is that "container root" is meant to point to any other YANG model. 

If a device "X" is mounted onto ODL, a controller talking to ODL could send a "bbf-network-manager" request through ODL to the mounted device. The YANG could have a "root" container which points to any other YANG model for example. 

This issue deals with notifications in particular - where a  notification comes into ODL for a BBF NETCONF device and is pointing to another YANG model using the "root" container:
<target xmlns:baa-network-manager="urn:bbf:yang:obbaa:network-manager" xmlns:bbf-xpongemtcont="urn:bbf:yang:bbf-xpongemtcont">/baa-network-manager:network-manager/baa-network-manager:managed-devices/baa-network-manager:device[baa-network-manager:name='myDevice']/baa-network-manager:root/bbf-xpongemtcont:xpongemtcont/bbf-xpongemtcont:tconts/bbf-xpongemtcont:tcont[bbf-xpongemtcont:name='tcont_ont1_2_0']</target>
For example  - this target is using the "root" concept to point to another yang model called "bbf-xpongemtcont"

BBF is using Yang 1.1 models, and this use of "root" to point to any other YANG model is the issue. 

Comment by Robert Varga [ 01/Feb/22 ]

Understood, but please note that in order to under stand what the device means when it says "baa-network-manager:root/" it must also populate the appropriate data in its operational datastore, as specified by RFC8528, specifically /schema-mounts/mount-points[module='baa-network-manager', label='root'. If it does not, the device is broken and there is nothing we can do simply because the device is violating the RFC and we have absolutely no idea how to interpret that mount-point instance.

Without seeing the contents of that list entry, I cannot begin to speculate as to what to do with this issue.

Comment by Robert Magaldi [ 09/Feb/22 ]

Sorry.. when I tried to get information I didn't have access to to a real device (simulator only).
Here is some information
curl -X GET "http://10.184.144.176:8181/restconf/data/network-topology:network-topology/topology=topology-netconf/node=Lowell-vOLT1/yang-ext:mount/ietf-yang-schema-mount:schema-mounts?content=nonconfig" -H "accept: application/xml"

<schema-mounts xmlns="urn:ietf:params:xml:ns:yang:ietf-yang-schema-mount">
<mount-point>

<module>network-manager</module>
<label>root</label>
<config>true</config>
</mount-point>
<namespace>
<prefix>network-manager</prefix>
<uri>urn:bbf:yang:obbaa:network-manager</uri>
</namespace>
</schema-mounts>

Guessing here.. This problem may be related to the yang tool file "XpathStringParsingPathArgumentBuilder.java" under yang/yang-data-util/src/main/java/org/opendaylight/yangtools...

It seems when parsing a "root", ODL doesn't go back to its original list of schema context to see if it can figure it out.

Generated at Wed Feb 07 20:55:54 UTC 2024 using Jira 8.20.10#820010-sha1:ace47f9899e9ee25d7157d59aa17ab06aee30d3d.