Re: "unknown namespace: unknown__xmlns in nc" error

leongovender · ‎10-18-2022

Hi,

We currently have a custom l2vpn service for NSO. There are requirements to update the service and in certain instance replace a portion of the config in its entirety. This used to work on NSO 5.2 but when testing against NSO ver 5.7, it fails.

The curl generated code from POSTMAN looks like this:

curl --location --request PATCH 'http://localhost:48080/restconf/data/' \
--header 'Accept: application/yang-data+json' \
--header 'Content-Type: application/yang-data+json' \
--header 'Authorization: Basic xxx' \
--data-raw '{
  "services": {
    "l2vpn:l2vpn": [
      {
        "service-type": "L2VPN_1_6",
        "name": "l2vpn-1-6-disable_storm",
        "commit-device-config": "true",
        "evpn-instance-global": {
          "l2vpn": {
            "bridge-group": {
              "bridge-domain": {
                "_xmlns:nc": "urn:ietf:params:xml:ns:netconf:base:1.0",
                "_nc:operation": "replace",
                "storm-control-type": [
                  {
                    "storm-control-type": "disabled"
                  }
                ]
              }
            }
          }
        }
      }
    ]
  }
}'
 
The error I get is:
{
    "ietf-restconf:errors": {
        "error": [
            {
                "error-type": "application",
                "error-tag": "malformed-message",
                "error-path": "",
                "error-message": "unknown namespace: unknown__xmlns in nc"
            }
        ]
    }
}
 
The existing service looks like this:
{
    "data": {
      "tailf-ncs:services": {
        "l2vpn:l2vpn": [
          {
            "service-type": "L2VPN_1_6",
            "name": "l2vpn-1-6-disable_storm",
            "commit-device-config": true,
            "evpn-instance-global": {
              "ethernet-segment-identifier": "00.00.00.13.13.13.13.44.89",
              "l2vpn": {
                "bridge-group": {
                  "bridge-domain": {
                    "storm-control-type": [
                      {
                        "storm-control-type": "pps",
                        "storm-control": {
                          "unknown-unicast-pps": 9000,
                          "multicast-pps": 9500,
                          "broadcast-pps": 9500
                        }
                      },
                      {
                        "storm-control-type": "kbps",
                        "storm-control": {
                          "unknown-unicast-kbps": 5000,
                          "multicast-kbps": 5500,
                          "broadcast-kbps": 5500
                        }
                      }
                    ]
                  }
                }
              }
            },
            "endpoint": [
              {
                "id": "1",
                "access-pe": "za-gp-viplab-pe-1",
                "if-type": {
                  "PW-Ether": {
                    "if-num": 1010
                  }
                },
                "if-qos-bandwidth": "1000",
                "qos-policy-map": {
                  "ingress-qpm": "is-pm-nso-q-i-p-o28-c4-r33-p33-g20-s12",
                  "egress-qpm": "is-pm-nso-q-e-p-o28-c4-r33-p33-g20-s12"
                },
                "attachment-circuit-topology": "dual-homed",
                "ethernet-segment-identifier": "00.00.00.11.11.11.11.44.88",
                "l2vpn": {
                  "bridge-group": {
                    "bridge-domain": {
                      "l2vpn-pw-mode": "acpw",
                      "asw-pw-class": "is-pc-asw1-npu0",
                      "asw-acpw-ip": "10.0.0.12",
                      "asw-pw-id": 1245,
                      "storm-control-type": [
                        {
                          "storm-control-type": "disabled"
                        }
                      ]
                    }
                  }
                }
              },
              {
                "id": "2",
                "access-pe": "za-gp-viplab-pe-3",
                "if-type": {
                  "PW-Ether": {
                    "if-num": 1012
                  }
                },
                "if-qos-bandwidth": "1000",
                "qos-policy-map": {
                  "ingress-qpm": "is-pm-nso-q-i-p-o28-c4-r33-p33-g20-s12",
                  "egress-qpm": "is-pm-nso-q-e-p-o28-c4-r33-p33-g20-s12"
                },
                "attachment-circuit-topology": "single-homed",
                "ethernet-segment-identifier": "00.00.00.11.11.11.11.44.66",
                "l2vpn": {
                  "bridge-group": {
                    "bridge-domain": {
                      "l2vpn-pw-mode": "acpw"
                    }
                  }
                }
              }
            ]
          }
        ]
      }
    }
  }
 
 I can find no documentation on the use of a restconf call in this manner. Please someone assist in correcting the error and if possible pointing me
to the relevant documentation.

perander · ‎10-18-2022

Naming a node "_xmlns:nc" is not a valid node identifier, if there isn't a
prefix defined as "_xmlns" somewhere. Analogous for "_nc:operation".
See RFC 7950 Section 14 YANG ABNF Grammar, e.g.:

node-identifier = [prefix ":"] identifier

It is hard to tell but it doesn't seem like _xmlns nor _nc are model prefixes.
What is the reason for why these two leafs are included in the payload?
Are these leafs included to try and set "nc:operation"? It is not possible
to specify operations the same way with RESTCONF as it is with NETCONF,
e.g. it is not possible to specify "nc:operation".

For further information about adding annotations to JSON encoded YANG,
see RFC 7951 and RFC 7952.

Furthermore, using RESTCONF Plain Patch imposes some limitations, e.g.
the corresponding "nc:operation" is merge. If more granular control is
needed check out RFC 8072 YANG Patch.

perander · ‎10-18-2022

Note that for JSON it should be module name which is used as prefix,
not the prefix defined in the YANG model. This means, for "_xmlns:nc"
to be a valid node identifier, a module named _xmlns.yang is required.

leongovender · ‎10-18-2022

Hi Perander,

Thank you for having a look at this.

You are correct, these two leafs _xmlns and _nc, are used to replace that specific container, and a standard merge on the rest of the payload. I have never seen this before, but it seems it is possible. I have replicated the issue and with all else being equal, it works in NSO v5.2, but doesn't work in NSO v5.7. i.e I use the same service package in both NSO versions and I apply the same steps to configure the service.

I have also searched in our stage environment(NSO v5.2) ,where it works, for files named _xmlns.yang, and for any file containing _xmlns, with no hits.

The yang-patch looks like it could be an alternative to what we are doing here, but that would mean changes to other systems

perander · ‎10-18-2022

There has never been any support in RESTCONF for explicitly setting "nc:operation".

I just tried supplying "_xmlns:nc" and "_nc:operation" on a 5.2 release and it does
not work, I get an HTTP 400 error.

leongovender · ‎10-18-2022

Hi perander,

I have changed the payload to something that should be more easily reproducible. I just had a description on the admin-state of a device, and then I posted a call to replace the state with admin-state and without the description. It worked as well.

leongo@ncs(config-device-za-gp-viplab-pe-4)# end
leongo@ncs# show running-config devices device za-gp-viplab-pe-4 state
devices device za-gp-viplab-pe-4
state admin-state southbound-locked
state admin-state-description testing
!
leongo@ncs#
System message at 2022-10-18 17:55:40...
Commit performed by leongo via https using rest.
leongo@ncs# show running-config devices device za-gp-viplab-pe-4 state
devices device za-gp-viplab-pe-4
state admin-state southbound-locked
!

leongo@ncs# show packages package cisco-iosxr-cli-7.38 package-version
package-version 7.38.2
leongo@ncs#

leongo@ncs# show ncs-state version
ncs-state version 5.2.3.3
leongo@ncs#

&quot;unknown namespace: unknown__xmlns in nc&quot; error

"unknown namespace: unknown__xmlns in nc" error