https://jira.opendaylight.org This file is an XML representation of an issue en-us 8.20.10 820010 22-06-2022 https://jira.opendaylight.org/browse/NETCONF-335 netconf <p>I'm not sure how we haven't noticed this before. Or maybe we have and decided not to fix it?</p> <p>ODL NETCONF sets default-operation to "none" southbound when using RESTCONF PUT or POST to modify a mounted device.</p> <p>that's fine for e.g. adding a new item to a list as config already exists at that level.</p> <p>but when adding new config it fails - correctly as far as I can tell from reading the relevant section of RFC6241:</p> <p> none: The target datastore is unaffected by the configuration<br/> in the &lt;config&gt; parameter, unless and until the incoming<br/> configuration data uses the "operation" attribute to request<br/> a different operation. If the configuration in the &lt;config&gt;<br/> parameter contains data for which there is not a<br/> corresponding level in the target datastore, an &lt;rpc-error&gt;<br/> is returned with an &lt;error-tag&gt; value of data-missing.<br/> Using "none" allows operations like "delete" to avoid<br/> unintentionally creating the parent hierarchy of the element<br/> to be deleted.</p> <p>So in this case I'm getting rpc-error from the mounted device with an error-tag value of data missing...</p> <p>Operating System: All<br/> Platform: All</p> NETCONF-335

NETCONF's default-operation of "none" prevents config creation

Bug Resolved Won't Do Unassigned Giles Heron Tue, 10 Jan 2017 11:10:12 +0000 Fri, 15 Mar 2019 22:22:34 +0000 Mon, 17 Jul 2017 13:12:47 +0000 restconf-nb 0 6 <p>an example of the XML sent to to XR by ODL:</p> <p>&lt;rpc message-id="m-4" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"&gt;<br/> &lt;edit-config&gt;<br/> &lt;target&gt;<br/> &lt;candidate/&gt;<br/> &lt;/target&gt;<br/> &lt;default-operation&gt;none&lt;/default-operation&gt;<br/> &lt;error-option&gt;rollback-on-error&lt;/error-option&gt;<br/> &lt;config&gt;<br/> &lt;ipv4-acl-and-prefix-list xmlns="http://cisco.com/ns/yang/Cisco-IOS-XR-ipv4-acl-cfg"&gt;<br/> &lt;accesses&gt;<br/> &lt;access xmlns:a="urn:ietf:params:xml:ns:netconf:base:1.0" a:operation="replace"&gt;<br/> &lt;access-list-name&gt;test-grant&lt;/access-list-name&gt;<br/> &lt;access-list-entries&gt;<br/> &lt;access-list-entry&gt;<br/> &lt;sequence-number&gt;10&lt;/sequence-number&gt;<br/> &lt;protocol&gt;igmp&lt;/protocol&gt;<br/> &lt;grant&gt;permit&lt;/grant&gt;<br/> &lt;/access-list-entry&gt;<br/> &lt;/access-list-entries&gt;<br/> &lt;/access&gt;<br/> &lt;/accesses&gt;<br/> &lt;/ipv4-acl-and-prefix-list&gt;<br/> &lt;/config&gt;<br/> &lt;/edit-config&gt;<br/> &lt;/rpc&gt;</p> <p>then:</p> <p>&lt;rpc message-id="m-5" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"&gt;<br/> &lt;commit/&gt;<br/> &lt;/rpc&gt;</p> <p>XR responded with:</p> <p>&lt;rpc-reply message-id="m-4" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"&gt;<br/> &lt;rpc-error&gt;<br/> &lt;error-type&gt;application&lt;/error-type&gt;<br/> &lt;error-tag&gt;data-missing&lt;/error-tag&gt;<br/> &lt;error-severity&gt;error&lt;/error-severity&gt;<br/> &lt;error-path xmlns:ns1="http://cisco.com/ns/yang/Cisco-IOS-XR-ipv4-acl-cfg"&gt;ns1:ipv4-acl-and-prefix-list&lt;/error-path&gt;<br/> &lt;/rpc-error&gt;<br/> &lt;/rpc-reply&gt;</p> <p>Hi Giles,</p> <p>Can you please give us also details about your RESTCONF call? Payload, URI and HTTP operation.</p> <p>for this one I POSTed to:</p> <p><a href="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" class="external-link" target="_blank" rel="nofollow noopener">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</a></p> <p>The contents were:</p> <p>{ "Cisco-IOS-XR-ipv4-acl-cfg:access":<br/> [<br/> {<br/> "access-list-name": "test-grant",<br/> "access-list-entries": {<br/> "access-list-entry": [</p> { "sequence-number": 10, "grant": "permit", "protocol": "igmp" } <p> ]<br/> }<br/> }<br/> ]<br/> }</p> <p>with no ACLs already on the router this fails. With one or more ACLs configured via CLI it succeeds.</p> <p>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.</p> <p>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).</p> <p>I had to have a look at RESTCONF and try this to see the exact behavior.</p> <p>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.</p> <p>Can you please give us also previous rpc messages ODL sent to your mounted device and rpc replies to those messages?</p> <p>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.</p> <p>Actually, the previous RPCs are relevant. They should ensure that parent nodes exist. So seeing them can help us to solve this issue.</p> <p>ah - so ODL adds the top level containers before trying to add the specific config?</p> <p>will attach logs (they start once the ASR9K is mounted).</p> <p>Attachment acl.log has been added with description: logs (with initial mounting deleted)</p> <p>(In reply to Giles Heron from comment #7)<br/> &gt; ah - so ODL adds the top level containers before trying to add the specific<br/> &gt; config?<br/> &gt; <br/> &gt; will attach logs (they start once the ASR9K is mounted).</p> <p>Yup, I have checked your logs and it turns it out, that ODL is trying to create parents prior to writing actual list item.</p> <p>Can you try to create empty containers on your device and see if they are really created?</p> <p>Hi Jakub,</p> <p>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).</p> <p>Giles</p> <p>is there any update on this?</p> <p>Hi Giles, sorry, looks like I've forgot about this one.</p> <p>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.</p> <p>Hi Jakub</p> <p>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).</p> <p>e.g. if, in configure, mode you type "ipv4 access-list" and then hit "?" then "&lt;cr&gt;" isn't one of the options given (as it would be if you could create an empty container).</p> <p>in terms of the NETCONF/YANG implementation on the device containers only get created:<br/> 1) if they have presence<br/> 2) when a list (or other) item gets created within the context of a container that has yet to be created.</p> <p>I believe this behaviour is consistent with section 7.5.1 of RFC6020:</p> <p> For example, the set of scrambling options for Synchronous Optical<br/> Network (SONET) interfaces may be placed inside a "scrambling"<br/> container to enhance the organization of the configuration hierarchy,<br/> and to keep these nodes together. The "scrambling" node itself has<br/> no meaning, so removing the node when it becomes empty relieves the<br/> user from performing this task.</p> <p>I'll move this bug to RESTCONF since the issue is there rather than in NETCONF.</p> <p>Giles</p> <p>Hi Giles, Jakub,<br/> I was suffering the same problem by directly using POST/PUT method on iosxrv device. It can be solved in 2 different ways.<br/> 1.I could create a parent node with child node filled. But it i if there are not safe when seversal configuration sessions.<br/> 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".<br/> 2.Using YANG PATCH to build customized netconf request. But YANG PATCH implementation has many other problem (issues <a href="https://jira.opendaylight.org/browse/NETCONF-367" title="Error parsing namespace when using YANG PATCH with absolute target path" class="issue-link" data-issue-key="NETCONF-367"><del>NETCONF-367</del></a>, <a href="https://jira.opendaylight.org/browse/NETCONF-360" title="simple list dosen&#39;t work in PATCH operation" class="issue-link" data-issue-key="NETCONF-360"><del>NETCONF-360</del></a>, <a href="https://jira.opendaylight.org/browse/NETCONF-374" title="Json HTTP PATCH: Problem parsing simple leaf value" class="issue-link" data-issue-key="NETCONF-374"><del>NETCONF-374</del></a>). Luckily, following request can be successfully create a child node even if its parent node doesn't exist.<br/> PATCH <a href="http://localhost:8181/restconf/config/network-topology:network-topology/topology/topology-netconf/node/iosxrv-7/yang-ext:mount/" class="external-link" target="_blank" rel="nofollow noopener">http://localhost:8181/restconf/config/network-topology:network-topology/topology/topology-netconf/node/iosxrv-7/yang-ext:mount/</a><br/> {<br/> "ietf-yang-patch:yang-patch": {<br/> "patch-id": "VPN-CREATION-1",<br/> "comment": "Create VPN-1",<br/> "edit": [<br/> {<br/> "edit-id": "1",<br/> "operation": "create",<br/> "target": "/Cisco-IOS-XR-infra-rsi-cfg:vrfs/Cisco-IOS-XR-infra-rsi-cfg:vrf<span class="error">&#91;Cisco-IOS-XR-infra-rsi-cfg:vrf-name=&#39;vpn-78&#39;&#93;</span>",<br/> "value": {<br/> "vrf": [<br/> {<br/> "vrf-name": "vpn-78",<br/> "create": [<br/> ],<br/> "afs": {<br/> "af": [<br/> </p> { "af-name": "ipv6", "saf-name": "unicast", "topology-name": "default", "create": [] } <p>,<br/> {<br/> "af-name": "ipv4",<br/> "saf-name": "unicast",<br/> "topology-name": "default",<br/> "create": [<br/> ],<br/> "Cisco-IOS-XR-ipv4-bgp-cfg:bgp": {<br/> "import-route-targets": {<br/> "route-targets": {<br/> "route-target": [<br/> {<br/> "type": "as",<br/> "as-or-four-byte-as": [<br/> </p> { "as-xx": "0", "as": "4804", "as-index": "1", "stitching-rt": "0" } <p>]<br/> }<br/> ]<br/> }<br/> },<br/> "export-route-targets": {<br/> "route-targets": {<br/> "route-target": [<br/> {<br/> "type": "as",<br/> "as-or-four-byte-as": [</p> { "as-xx": "0", "as": "4804", "as-index": "1", "stitching-rt": "0" } <p> ]<br/> }<br/> ]<br/> }<br/> }<br/> }<br/> }<br/> ]<br/> },<br/> "description": "vrf for VPN which connects each site from iosxrv-7 and iosxrv-8",<br/> "vpn-id": </p> { "vpn-oui": "4804", "vpn-index": "1" } <p> }<br/> ]<br/> }<br/> }<br/> }<br/> }<br/> }</p> <p>is there any plan to fix this?</p> <p>Hi,</p> <p>I am using Cisco IOS XR-5.3.0</p> <p>Even after configuring ACLs via CLI, it's not working and I'm getting the error as :</p> <p>&lt;errors xmlns="urn:ietf:params:xml:ns:yang:ietf-restconf"&gt;&lt;error&gt;&lt;error-type&gt;protocol&lt;/error-type&gt;&lt;error-tag&gt;unknown-element&lt;/error-tag&gt;&lt;error-message&gt;"yang-ext" module does not exist in mount point.&lt;/error-message&gt;&lt;/error&gt;&lt;/errors&gt;</p> <p>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.</p> <p>Do ping me offline (giheron@cisco.com)</p> <p>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.</p> <p>Hi Thomas</p> <p>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.</p> <p>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.</p> <p>Giles</p> <p>RFC 6241<br/> section 8.3.1 states:<br/> The candidate configuration capability, :candidate, indicates that<br/> the device supports a candidate configuration datastore, which is<br/> used to hold configuration data that can be manipulated without<br/> impacting the device's current configuration. The candidate<br/> configuration is a full configuration data set that serves as a work<br/> place for creating and manipulating configuration data. Additions,<br/> deletions, and changes can be made to this data to construct the<br/> desired configuration data.</p> <p>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.</p> <p>my bad - looks like there may be a fix in the latest XR. Am just trying to clarify.</p> <p>still don't buy that it's explicit though <img class="emoticon" src="https://jira.opendaylight.org/images/icons/emoticons/wink.png" height="16" width="16" align="absmiddle" alt="" border="0"/></p> <p>Yes - fixed in XR 6.2.1.</p> <p>Figuring that out required me to raise one bug against Yangtools and comment against another Yangtools bug. but there you go...</p> Development External issue ID 7506 External issue URL Priority Rank 0|i01xwn: