Action Reply Error

CDB and CDB API
1

Hi,

I have the following Yang:

` container network-instances {
    action loopback {
            description "Loopback";
            input {
              leaf name {
              type string;
              }
            }
                output {

                  leaf oname {
                  type string;
                  }
              }
        }
    
    }

The registration successfully works. And I am able to call the action as well. However, when I try to return the reply it fails with this on Mgsoft browser:

*[2019/07/31 14:37:15]* Command 16f4cb7a-cfae-46b0-b5ed-58c64b51f8db:8; unknown was unsuccessful. Error reported:

*[2019/07/31 14:37:15]* command timed out

I ran this XML:

<?xml version="1.0" encoding="utf-8"?>
<rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"
     xmlns:yang-1_1="urn:ietf:params:xml:ns:yang:1"
     xmlns:ni="urn:ietf:params:xml:ns:yang:ietf-network-instance"
     message-id="1">
  <action xmlns="urn:ietf:params:xml:ns:yang:1">
    <network-instances xmlns="urn:ietf:params:xml:ns:yang:ietf-network-instance">
      <loopback>
        <name>x</name>
      </loopback>
    </network-instances>
  </action>
</rpc>

My code for returning action reply:

    confd_tag_value_t reply[15];
    int i=0;
    CONFD_SET_TAG_XMLBEGIN(&reply[i], ni_loopback, ni__ns); i++;
    CONFD_SET_TAG_STR(&reply[i], ni_oname, "hello" ); i++;                                                                                                                                                                                                                 
    CONFD_SET_TAG_XMLEND(&reply[i], ni_loopback, ni__ns); i++;
    confd_action_reply_values(uinfo, reply, i);

Is there anything wrong with the above code snippet? I have implemented it similar to the example provided in the Confd manual.

Moreover, when I print reply I get the following:

ConfDAdaptorNetworkInstancesLoopback::ActionReply : Reply   0: 1046154078:343067885, tag<343067885>
ConfDAdaptorNetworkInstancesLoopback::ActionReply : Reply   1:         0:1580536827, "hello"
ConfDAdaptorNetworkInstancesLoopback::ActionReply : Reply   2: 1046154078:343067885, tag<343067885>

In the confd_devel.log, I found this:
devel-c bad return tag for loopback in 'urn:ietf:params:xml:ns:yang:ietf-network-instance': /network-instances/loopback/$output/loopback/oname

The confd compiler returns the required tags and namespaces.

Please suggest a solution for this problem.
Thanking you in advance.

Regards,
Ramakrishnan

2

That’s a pretty strange error message, but in any case the problem should be that only the nodes that are descendants of the output statement should be passed in the array to confd_action_reply_values(). I.e. in your case that is just the oname leaf - drop the XMLBEGIN/XMLEND for loopback.

3

Thanks per, that doesn’t solve the problem though. How will I be able to view my action reply that is sent? I am using the Mgsoft Netconf browser as I will not be able to see the reply using confd_cli.

4

Surely you are not getting the exact same error message if you don’t include the loopback elements in the reply array? Strange wording or not, ConfD can’t very well complain about loopback if you aren’t actually passing it in confd_action_reply_values().

If an error is logged in the developerLog for your reply, it means that ConfD isn’t able to generate the XML for the reply based on the data you sent, so there is no actual action reply to see. You can see a low-level representation of the exact data you are sending to ConfD by using CONFD_PROTO_TRACE for the debug level in confd_init().

5

Per,

I removed the XMLBEGIN and XMLEND correctly just now.
Thanks, I am able to see the output in the form of an XML.

Regards,
Ramakrishnan

6 
action show-meg-status {
        tailf:actionpoint showmegstatus;
        description "Show MEG Status";
        input {
                leaf meg-name {
                        type eci-tp-oam-types:meg-name;
                        mandatory true;
                }
        }
        output {                                                                                                                                                                                                                                           
                container meg-status {
                         uses "meg-status";
                }
        }
}//action show-meg-status


  grouping meg-status {                                                                                                                                                                                                                                                  
        leaf cos {
                        type eci-tp-oam-types:cos;
                        config false;
                }
                leaf ccm-interval {
                        type eci-tp-oam-types:ccm-interval;
                        config false;
                }
                leaf operational-status {
                        type eci-tp-oam-types:operational-status;
                        config false;
                }
                leaf mep-id{
                        type eci-tp-oam-types:mep-id;
                        config false;
                }
                leaf remote-mep-id {
                        type eci-tp-oam-types:mep-id;
                        config false;
                }
...
}

How can I generated my action reply?

I have the following code snippet

confd_tag_value_t reply[13];
int i = 0;

CONFD_SET_TAG_UINT8(&reply[i], eci_srtp_oam_aug_cos, Reply->CcmCos); i++;
CONFD_SET_TAG_ENUM_VALUE(&reply[i], eci_srtp_oam_aug_ccm_interval,Reply->CcmInterval); i++;
CONFD_SET_TAG_BOOL(&reply[i], eci_srtp_oam_aug_operational_status, Reply->OperState); i++;
CONFD_SET_TAG_UINT16(&reply[i], eci_srtp_oam_aug_mep_id, Reply->MepID); i++;
CONFD_SET_TAG_UINT16(&reply[i], eci_srtp_oam_aug_remote_mep_id, Reply->RmtMepID); i++;
CONFD_SET_TAG_BOOL(&reply[i], eci_srtp_oam_aug_rdi_sent, Reply->RDISent); i++;
CONFD_SET_TAG_BOOL(&reply[i], eci_srtp_oam_aug_rdi_received, Reply->RDIRcv); i++;
CONFD_SET_TAG_BOOL(&reply[i], eci_srtp_oam_aug_ais_received, Reply->AisRcv); i++;
CONFD_SET_TAG_BOOL(&reply[i], eci_srtp_oam_aug_csf_received, Reply->CsfRcv); i++;
CONFD_SET_TAG_BOOL(&reply[i], eci_srtp_oam_aug_lck_received, Reply->LckRcv); i++;
CONFD_SET_TAG_BOOL(&reply[i], eci_srtp_oam_aug_sd_received, Reply->SDRcv); i++;

confd_action_reply_values(uinfo, reply, i);

However, I get the following error:
Error: bad response from action

How am I supposed to handle grouping/container meg-status? Is that causing the issue?

Thanks in advance.

7

As I wrote earlier:

The use of a grouping is “invisible” in the schema, i.e. the uses statement is effectively replaced with the contents of the grouping - but your container is precisely “a node that is a descendant of the output statement”, and must be included in the array. You can find the exact rules for populating the array in the section “Tagged Value Array” in the confd_types(3) manual page - it’s basically a “flattened” representation of the XML. Specifically, you need to start the array with XMLBEGIN for the container and end it with XMLEND for the container.

The missing array elements for the container is at least one problem that needs to be fixed.

Another possibility is of course to remove the container from the data model, i.e. have the uses statement as a direct substatement of output. With an action called show-meg-status, wrapping the reply in a container called meg-status doesn’t really add any value…

8

Thanks Per. I have added XMLBEGIN and XMLEND but I am still facing an issue.

confd_tag_value_t reply[16];
int i = 0;

CONFD_SET_TAG_XMLBEGIN(&reply[i], eci_srtp_oam_aug_meg_status, eci_srtp_oam_aug__ns); i++;
CONFD_SET_TAG_UINT8(&reply[i], eci_srtp_oam_aug_cos, Reply->CcmCos); i++;
CONFD_SET_TAG_ENUM_VALUE(&reply[i], eci_srtp_oam_aug_ccm_interval,Reply->CcmInterval); i++;
CONFD_SET_TAG_BOOL(&reply[i], eci_srtp_oam_aug_operational_status, Reply->OperState); i++;
CONFD_SET_TAG_UINT16(&reply[i], eci_srtp_oam_aug_mep_id, Reply->MepID); i++;
CONFD_SET_TAG_UINT16(&reply[i], eci_srtp_oam_aug_remote_mep_id, Reply->RmtMepID); i++;
CONFD_SET_TAG_BOOL(&reply[i], eci_srtp_oam_aug_rdi_sent, Reply->RDISent); i++;
CONFD_SET_TAG_BOOL(&reply[i], eci_srtp_oam_aug_rdi_received, Reply->RDIRcv); i++;
CONFD_SET_TAG_BOOL(&reply[i], eci_srtp_oam_aug_ais_received, Reply->AisRcv); i++;
CONFD_SET_TAG_BOOL(&reply[i], eci_srtp_oam_aug_csf_received, Reply->CsfRcv); i++;
CONFD_SET_TAG_BOOL(&reply[i], eci_srtp_oam_aug_lck_received, Reply->LckRcv); i++;
CONFD_SET_TAG_BOOL(&reply[i], eci_srtp_oam_aug_sd_received, Reply->SDRcv); i++;
CONFD_SET_TAG_BOOL(&reply[i], eci_srtp_oam_aug_sd_received, true); i++;
CONFD_SET_TAG_XMLEND(&reply[i], eci_srtp_oam_aug_meg_status, eci_srtp_oam_aug__ns); i++;

confd_action_reply_values(uinfo, reply, i);

XML INPUT

<action xmlns="urn:ietf:params:xml:ns:yang:1"
        xmlns:yang-1_1="urn:ietf:params:xml:ns:yang:1"
        xmlns:eci-srtp-oam-aug="urn:eci:params:xml:ns:yang:eci-srtp-oam-aug">
  <domains xmlns="urn:ietf:params:xml:ns:yang:ietf-connection-oriented-oam">
    <domain>
      <technology xmlns:eci-mplstpoam-aug="urn:eci:params:xml:ns:yang:eci-mplstpoam-aug">eci-mplstpoam-aug:mpls-tp</technology>
      <md-name-string>none</md-name-string>
      <sr-tp xmlns="urn:eci:params:xml:ns:yang:eci-srtp-oam-aug">
        <meg>
          <meg-name>x</meg-name>
          <actions>
            <show-meg-status>
              <meg-name>x</meg-name>
            </show-meg-status>
          </actions>
        </meg>
      </sr-tp>
    </domain>
  </domains>
</action>

OUTPUT

<?xml version="1.0" encoding="utf-8"?>
<rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="198">
  <rpc-error>
    <error-type>application</error-type>
    <error-tag>data-missing</error-tag>
    <error-severity>error</error-severity>
    <error-path xmlns:eci-srtp-oam-aug="urn:eci:params:xml:ns:yang:eci-srtp-oam-aug"
                xmlns:co-oam="urn:ietf:params:xml:ns:yang:ietf-connection-oriented-oam">
    /co-oam:domains/co-oam:domain[co-oam:technology='eci-mplstpoam-aug:mpls-tp'][co-oam:md-name-string='none']/eci-srtp-oam-aug:sr-tp/eci-srtp-oam-aug:meg[eci-srtp-oam-aug:meg-name='x']
  </error-path>
    <error-info>
      <bad-element>actions</bad-element>
    </error-info>
  </rpc-error>
</rpc-reply>
9

The rpc-error seems fairly clear (and since it prevents invocation of your callback, it has nothing to do with what you pass to confd_action_reply_values()). According to RFC 6241 - Network Configuration Protocol (NETCONF) the <error-tag> data-missing means “Request could not be completed because the relevant data model content does not exist.” And the thing that is missing is the <bad-element>, i.e. the actions child of the long and winding <error-path>. Assuming that your XML matches the data model, actions is a container, and the fact that it is missing implies that it is a presence container that hasn’t been created.

As an aside, you haven’t shared that part of the data model, but I get the impression that actions is there just to contain a set of action nodes - i.e. a perfect example of the description “existing only to contain child nodes” for containers without presence in RFC 7950 - The YANG 1.1 Data Modeling Language . For a presence container, “the presence of the container itself carries some meaning” - you should ask yourself “What is the meaning of your actions container being present in the data tree?”. (Actually that meaning should supposedly be given by the argument to the presence statement.)