Operating System: All
Platform: All

an example of the XML sent to to XR by ODL:

<rpc message-id="m-4" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<edit-config>
<target>
<candidate/>
</target>
<default-operation>none</default-operation>
<error-option>rollback-on-error</error-option>
<config>
<ipv4-acl-and-prefix-list xmlns="http://cisco.com/ns/yang/Cisco-IOS-XR-ipv4-acl-cfg">
<accesses>
<access xmlns:a="urn:ietf:params:xml:ns:netconf:base:1.0" a:operation="replace">
<access-list-name>test-grant</access-list-name>
<access-list-entries>
<access-list-entry>
<sequence-number>10</sequence-number>
<protocol>igmp</protocol>
<grant>permit</grant>
</access-list-entry>
</access-list-entries>
</access>
</accesses>
</ipv4-acl-and-prefix-list>
</config>
</edit-config>
</rpc>

then:

<rpc message-id="m-5" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<commit/>
</rpc>

XR responded with:

<rpc-reply message-id="m-4" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<rpc-error>
<error-type>application</error-type>
<error-tag>data-missing</error-tag>
<error-severity>error</error-severity>
<error-path xmlns:ns1="http://cisco.com/ns/yang/Cisco-IOS-XR-ipv4-acl-cfg">ns1:ipv4-acl-and-prefix-list</error-path>
</rpc-error>
</rpc-reply>

Hi Giles,

Can you please give us also details about your RESTCONF call? Payload, URI and HTTP operation.

for this one I POSTed to:

http://localhost:8181/restconf/config/network-topology:network-topology/topology/topology-netconf/node/asr9k1/yang-ext:mount/Cisco-IOS-XR-ipv4-acl-cfg:ipv4-acl-and-prefix-list/accesses

The contents were:

{ "Cisco-IOS-XR-ipv4-acl-cfg:access":
[
{
"access-list-name": "test-grant",
"access-list-entries": {
"access-list-entry": [

]
}
}
]
}

with no ACLs already on the router this fails. With one or more ACLs configured via CLI it succeeds.

I see similar behaviour with PUT/POST to the openconfig BGP model (same URL as above but ending openconfig-bgp:bgp. there I can't PUT or POST to the top level of the BGP config until config has been created from the CLI. And again I can't add BGP neighbors until one or more neighbors are already in the config.

This is all consistent as far as I can tell with ODL's use of default-operation==none and with the text in RFC6241. I suspect in these cases (where there is no corresponding level in the target datastore) we should be setting default-operation==replace).

I had to have a look at RESTCONF and try this to see the exact behavior.

ODL should create necessary parent nodes, in your case containers 'ipv4-acl-and-prefix-list' and 'accesses', so this should prevent these "data-missing" errors.

Can you please give us also previous rpc messages ODL sent to your mounted device and rpc replies to those messages?

hi - the previous RPCs were probably just me checking the router had mounted ok. At any rate this behaviour happens every time without fail - so previous messages don't seem that relevant. But can run another test if you want to see M=1.

Actually, the previous RPCs are relevant. They should ensure that parent nodes exist. So seeing them can help us to solve this issue.

ah - so ODL adds the top level containers before trying to add the specific config?

will attach logs (they start once the ASR9K is mounted).

Attachment acl.log has been added with description: logs (with initial mounting deleted)

(In reply to Giles Heron from comment #7)
> ah - so ODL adds the top level containers before trying to add the specific
> config?
>
> will attach logs (they start once the ASR9K is mounted).

Yup, I have checked your logs and it turns it out, that ODL is trying to create parents prior to writing actual list item.

Can you try to create empty containers on your device and see if they are really created?

Hi Jakub,

i don't think there's any way to create empty containers on XR as both of those containers contain lists where it's the list that has meaning (and which is created from the CLI).

Giles

is there any update on this?

Hi Giles, sorry, looks like I've forgot about this one.

Yeah, so as I have mentioned above, ODL is trying to create necessary parent nodes. This is done by creating empty containers. Maybe your device cannot cope with such modifications. So it would be helpful to know if your device is capable of creating empty containers.

Hi Jakub

no - as far as I know there's no way to create empty containers as semantically we just have a list in the router (I guess the list was wrapped in a container so we could use the container to get the whole list in a single operation).

e.g. if, in configure, mode you type "ipv4 access-list" and then hit "?" then "<cr>" isn't one of the options given (as it would be if you could create an empty container).

in terms of the NETCONF/YANG implementation on the device containers only get created:
1) if they have presence
2) when a list (or other) item gets created within the context of a container that has yet to be created.

I believe this behaviour is consistent with section 7.5.1 of RFC6020:

For example, the set of scrambling options for Synchronous Optical
Network (SONET) interfaces may be placed inside a "scrambling"
container to enhance the organization of the configuration hierarchy,
and to keep these nodes together. The "scrambling" node itself has
no meaning, so removing the node when it becomes empty relieves the
user from performing this task.

I'll move this bug to RESTCONF since the issue is there rather than in NETCONF.

Giles

Hi Giles, Jakub,
I was suffering the same problem by directly using POST/PUT method on iosxrv device. It can be solved in 2 different ways.
1.I could create a parent node with child node filled. But it i if there are not safe when seversal configuration sessions.
For example, I add a vrf in Cisco-IOS-XR-infra-rsi-cfg:vrfs, if there is no vrf in "vrfs" container, I cannot directly create a "vrf" within the "vrfs". But I can create the "vrfs" container which contains a "vrf".
2.Using YANG PATCH to build customized netconf request. But YANG PATCH implementation has many other problem (issues NETCONF-367, NETCONF-360, NETCONF-374). Luckily, following request can be successfully create a child node even if its parent node doesn't exist.
PATCH http://localhost:8181/restconf/config/network-topology:network-topology/topology/topology-netconf/node/iosxrv-7/yang-ext:mount/
{
"ietf-yang-patch:yang-patch": {
"patch-id": "VPN-CREATION-1",
"comment": "Create VPN-1",
"edit": [
{
"edit-id": "1",
"operation": "create",
"target": "/Cisco-IOS-XR-infra-rsi-cfg:vrfs/Cisco-IOS-XR-infra-rsi-cfg:vrf[Cisco-IOS-XR-infra-rsi-cfg:vrf-name='vpn-78']",
"value": {
"vrf": [
{
"vrf-name": "vpn-78",
"create": [
],
"afs": {
"af": [

,
{
"af-name": "ipv4",
"saf-name": "unicast",
"topology-name": "default",
"create": [
],
"Cisco-IOS-XR-ipv4-bgp-cfg:bgp": {
"import-route-targets": {
"route-targets": {
"route-target": [
{
"type": "as",
"as-or-four-byte-as": [

]
}
]
}
},
"export-route-targets": {
"route-targets": {
"route-target": [
{
"type": "as",
"as-or-four-byte-as": [

]
}
]
}
}
}
}
]
},
"description": "vrf for VPN which connects each site from iosxrv-7 and iosxrv-8",
"vpn-id":

}
]
}
}
}
}
}

is there any plan to fix this?

Hi,

I am using Cisco IOS XR-5.3.0

Even after configuring ACLs via CLI, it's not working and I'm getting the error as :

<errors xmlns="urn:ietf:params:xml:ns:yang:ietf-restconf"><error><error-type>protocol</error-type><error-tag>unknown-element</error-tag><error-message>"yang-ext" module does not exist in mount point.</error-message></error></errors>

Hi Sanjivini - that's a different bug. The error '"yang-ext" module does not exist in mount point' occurs because the model you're trying to use hasn't been mounted by ODL.

Do ping me offline (giheron@cisco.com)

Giles, I don't think it's correct that the device is ignoring the message that creates the parent structure. This would make sense if it was the running datastore, but in candidate the device cannot know what the user is intending to do with the data until commit, so it shouldn't do any pruning etc.

Hi Thomas

the problem is that that may be your interpretation - but it isn't stated explicitly in RFC6020 or RFC6241, and is at variance what the XR guys have implemented.

at the end of that day they're the "800lb gorilla" here, not ODL. So it's really down to us to figure out how to interoperate with them.

Giles

RFC 6241
section 8.3.1 states:
The candidate configuration capability, :candidate, indicates that
the device supports a candidate configuration datastore, which is
used to hold configuration data that can be manipulated without
impacting the device's current configuration. The candidate
configuration is a full configuration data set that serves as a work
place for creating and manipulating configuration data. Additions,
deletions, and changes can be made to this data to construct the
desired configuration data.

Considering that the rfc states that it serves as a "workplace for creating and manipulating configuration data" seems to me like its pretty explicit. But we can always write to the ietf mailing list to clarify this for us.

my bad - looks like there may be a fix in the latest XR. Am just trying to clarify.

still don't buy that it's explicit though

Yes - fixed in XR 6.2.1.

Figuring that out required me to raise one bug against Yangtools and comment against another Yangtools bug. but there you go...