Create a configurable list

YANG
1

Hi,
i have an interface list that is configurable. So is there any mechanism through which I can create an interface list having a key. So whenever from netconf client tries to read the list having a key, it can get all those values.
RPC for get operation through netconf client will be as below:

<rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="10"> 
   <get xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> 
     <filter type="xpath" xmlns:if="urn:ietf:params:xml:ns:yang:ietf-interfaces" select="/if:interfaces/interface[name='CUPLANE-VLAN-ETH1']"/> 
   </get> 
</rpc>

The idea is to server will create interface list having key.So later client can fetch all the leaf nodes of the respective key.
If I can get example then it will be really helpful.

Regards,
Biswajit

2

Not sure if I am on the right track, correct me if i’m wrong…
It sounds like this might be related to “auto-configuration” - a list that has entries created both by:

  • northbound user
  • originating/created by “backend”

that you want to make accessible to user as well?

3

Hi Joseph,
Thanks for your reply.
Since the radio knows how many interfaces are present,so the list of interfaces should be created by confd server only. While the server is coming up,it will configure confd database so that The netconf client can access the fields by providing the key name while in get operation as I have provided the RPC.

To summarize your query,it should not created by northbound user/netconf client as they wont be aware about radio.It should be created by backend/confd server.

Hope I am able to clarify your concern.

Regards,
Biswajit

4

Hi @Biswajit84,

Ok, so then the list is not configurable, but northbound interface non-writable state (config false) data. You then need to implement for example a data provider through the DP API.

Regards

5

Hi Conny,

When i have gone through the o-ran-interface.yang from which mac-address leaf nead to be configured is as below.It has not been mentioned whether config is true or false.Also when i have gone through the interface list present in ietf-interface.yang also couldn’t find .So i could conclude any answer to your query.
If you can conclude anything from the description then it will be really helpful.
So if you conclude it as config=false then do you suggest implement it as transactional callback using get-elem and get-next for list.

oran-interface.yang:

augment "/if:interfaces/if:interface" {
when "(if:type = 'ianaift:ethernetCsmacd') or
      (if:type = 'ianaift:l2vlan')" {
  description "Applies to ethernetCsmacd and l2vlan interfaces";
}
description
  "Augment the interface model with parameters for all
  both ethernetCsmacd and l2vlan interfaces.";
leaf mac-address {
  type yang:mac-address;
  description
    "The MAC address of the interface.";
}

ietf-interfaces.yang
 container interfaces {
description
  "Interface parameters.";

list interface {
  key "name";

  description
    "The list of interfaces on the device.
     The status of an interface is available in this list in the
     operational state.  If the configuration of a
     system-controlled interface cannot be used by the system
     (e.g., the interface hardware present does not match the
     interface type), then the configuration is not applied to
     the system-controlled interface shown in the operational
     state.  If the configuration of a user-controlled interface
     cannot be used by the system, the configured interface is
     not instantiated in the operational state.
     System-controlled interfaces created by the system are
     always present in this list in the operational state,
     whether or not they are configured.";
 }

Regards,
Biswajit

6

Hi Biswajit,
Default is config true. This is where you want to use an NMDA operational state callpoint and register an operational state data provider for that callpoint .

container interface {
  tailf:callpoint { tailf:operational }
...
}

FIrst read the NMDA rfc and the interfaces example https://tools.ietf.org/html/rfc8342#appendix-C.3
Then start with the simple $CONFD_DIR/examples.confd/nmda/02-origin-annotation/ ConfD example.

Regards

7

Hi Conny,
I am using confd-7.3 and I couldn’t find the nmda directory inside examples.confd.So if you can share the patch link and how to apply it confd then it will be really helpful.

Also I have created a annotation file of o-ran-interface-ann.yang having content as below.I used this while building ietf-interfaces.yang.
confdc --annotate o-ran-interfaces-ann.yang --fail-on-warnings -c -o ietf-interfaces.fxs ietf-interfaces.yang

while executing the above command,its giving error expected token separator.

o-ran-interfaces-ann.yang:

 module o-ran-interfaces-ann {

 yang-version 1.1;
 namespace "urn:ietf:params:xml:ns:yang:o-ran-interfaces:1.0";
 prefix o-ran-if-ann;
import ietf-interfaces {
 prefix if;
}
import tailf-common {
prefix tailf;
}
tailf:annotate "/if/interfaces/if:interface"
{
 tailf:callpoint {tailf:operational};
 }
 tailf:annotate "/if:interfaces/if:interface" {
tailf:callpoint cb_op_if_interface;
    }
}

Regards,
Biswajit

8

You need at least ConfD 7.4, preferably 7.5.x for NMDA support.

If you don’t want to make use of NMDA, you should support the old “interface-state” subtree in https://tools.ietf.org/html/rfc8343 with your operational-state configuration instead of doing device auto config changes to the “interface” subtree where only management clients should make changes.