IETF Logo Mail Archive

[Netconf] What should a server response be?

Mahesh Jethanandani <mjethanandani@gmail.com> Mon, 11 July 2016 20:48 UTC

Return-Path: <mjethanandani@gmail.com>
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C077F12D50E for <netconf@ietfa.amsl.com>; Mon, 11 Jul 2016 13:48:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uoq4oa_cs1M0 for <netconf@ietfa.amsl.com>; Mon, 11 Jul 2016 13:48:01 -0700 (PDT)
Received: from mail-pf0-x231.google.com (mail-pf0-x231.google.com [IPv6:2607:f8b0:400e:c00::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E3E4D12D0FA for <netconf@ietf.org>; Mon, 11 Jul 2016 13:48:00 -0700 (PDT)
Received: by mail-pf0-x231.google.com with SMTP id t190so39491562pfb.3 for <netconf@ietf.org>; Mon, 11 Jul 2016 13:48:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:subject:message-id:date:to:mime-version; bh=+d5viXsFw/16qTgoQLe7smei3/JtRZ/PiQhmD/RhYco=; b=PXsN3glvjA01Jt0s+0yUFV6KPNhRv+j3LUNgxPqXYi6PoIMhTikEiH3YfkcxU4dyWh nIOxnkQhvaNDtmkAAGWDTMAYHk+3kl6JFtHgIIPaKtBAR+G66eh/F0m3VWghKRiHmLGV CmcbB0yqTarrJaMdbvo2besJWt9nrT78c+QYzDz+8EWJoO9eGy7Ew56M+OUdOFkYd+A2 FcqdKbmzX5NdzAxUZj+e6vZ/YTTgrmUmP6a7Df4y1Yf8+YYuDBOP3oMNtpZrt+jx5EQw aijCGWHy0M7TDU7O2L7HpfgF2XGlDR7HcejpP7vR7wuEvh6IRHX8gRFBhbeSi8d1q9pn 9FOA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:subject:message-id:date:to:mime-version; bh=+d5viXsFw/16qTgoQLe7smei3/JtRZ/PiQhmD/RhYco=; b=d4+z0KR3qndyANGwq4kyIgEe1YaAGOQDVddMfxT83xYNP/fGjdpaW+8GYb8LPm3dU7 ORLUHGngAl06tXC8zW8XMqfGLLcuesiI2x4VdFz+cwEgqbL89uxJy19lFGbrUjh7FZ3h +nWcX0h6w6P1QmuBeh/XKRvHgq46NRmfj3SMizYajU3B4nb/LgLSgqAWPx3Tn5inL4fZ QvQpZw2IuU+jiq2mQJ455ZXy1HUfFKsY4cZz1fxpuO+qBN1RTT80EeWUvkfK/AsEHDiS Xjww5DrzRDEPwHo7o6dzJzv5QA+7AAX/6BaOKr0q4zZ7tqzH38zEU2Vr5HfyiUoOKAq7 gKcA==
X-Gm-Message-State: ALyK8tLbumUeXjFHaIkzwTPAsRy5Dls1mpO+gcN/vM8REd8E51+zxznXhxcZ51fv77cjgw==
X-Received: by 10.98.79.194 with SMTP id f63mr38185457pfj.95.1468270080167; Mon, 11 Jul 2016 13:48:00 -0700 (PDT)
Received: from ?IPv6:2001:420:30d:1320:c58d:7bd6:a7b:c2b7? ([2001:420:30d:1320:c58d:7bd6:a7b:c2b7]) by smtp.gmail.com with ESMTPSA id uj5sm6956383pac.28.2016.07.11.13.47.59 for <netconf@ietf.org> (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 11 Jul 2016 13:47:59 -0700 (PDT)
From: Mahesh Jethanandani <mjethanandani@gmail.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_72FCF3B0-817B-4EE1-B9C4-6AF935706C02"
Message-Id: <5DD335F5-5F82-471A-AFCB-A48D46FCD6AE@gmail.com>
Date: Mon, 11 Jul 2016 13:47:58 -0700
To: Netconf <netconf@ietf.org>
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
X-Mailer: Apple Mail (2.3124)
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/hHfV00YwFyfNw7WYMlik2kop6BM>
Subject: [Netconf] What should a server response be?
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netconf/>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 11 Jul 2016 20:48:03 -0000

The Opendaylight controller is constructing this particular set of <edit-config> requests as part of a single transaction. The response of the server is to reject the configuration that the particular node (evpn container) does not exist. 

However, if the default-operation=none is removed or changed to replace, the server responds with an RPC OK.

Is the server right in its interpretation of what RFC 6241 says? In particular, the way the server is interpreting this request is as follows from Section 7.2 of the RFC:

         none:  The target datastore is unaffected by the configuration
            in the <config> parameter, unless and until the incoming
            configuration data uses the "operation" attribute to request
            a different operation.  If the configuration in the <config>
            parameter contains data for which there is not a
            corresponding level in the target datastore, an <rpc-error>
            is returned with an <error-tag> value of data-missing.
            Using "none" allows operations like "delete" to avoid
            unintentionally creating the parent hierarchy of the element
            to be deleted.

and then this:

      operation:  Elements in the <config> subtree MAY contain an
         "operation" attribute, which belongs to the NETCONF namespace
         defined in Section 3.1 <https://tools.ietf.org/html/rfc6241#section-3.1>.  The attribute identifies the point in
         the configuration to perform the operation and MAY appear on
         multiple elements throughout the <config> subtree.


1st request:
 
<rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="m-23">
  <edit-config>
    <target>
      <candidate/>
    </target>
    <error-option>rollback-on-error</error-option>
    <config>
      <evpn xmlns="http://cisco.com/ns/yang/Cisco-IOS-XR-l2vpn-cfg <http://cisco.com/ns/yang/Cisco-IOS-XR-l2vpn-cfg>">
        <evpn-tables/>
      </evpn>
    </config>
  </edit-config>
</rpc>
##
 
The container evpn in this case is a non-presence container and does not contain any mandatory leafs or default statements. The server therefore interprets that nothing has to be done here, as it is not required to create a empty container.
 
2nd request:
 
<rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="m-24">
  <edit-config>
    <target>
      <candidate/>
    </target>
    <default-operation>none</default-operation>
    <error-option>rollback-on-error</error-option>
    <config>
      <evpn xmlns="http://cisco.com/ns/yang/Cisco-IOS-XR-l2vpn-cfg <http://cisco.com/ns/yang/Cisco-IOS-XR-l2vpn-cfg>">
        <evpn-tables>
          <evpn-load-balancing xmlns:a="urn:ietf:params:xml:ns:netconf:base:1.0" a:operation="replace">
            <enable/>
            <evpn-flow-label/>
          </evpn-load-balancing>
        </evpn-tables>
      </evpn>
    </config>
  </edit-config>
</rpc>
##

In the second request, the default-operation=none again seems to imply that nothing needs to be done for creation of the evpn node. Therefore by the time the evpn-load-balancing request rolls around, the request is rejected as the parent container does not exist. As stated earlier, if the default-operation is removed (causing a default of merge) or replaced with a replace, the transaction succeeds.

A second interpretation to this transaction is that the server should have created the evpn node as part of the first request, and that the none operation was implying that the node had already been created.

Which interpretation is correct, and what sections of the RFC can one cite to support the argument?

Thanks.

Mahesh Jethanandani
mjethanandani@gmail.com

v2.23.0 | Report a Bug | By Email