[netmod] Retrieving Information Pointed by leafref

"Xufeng Liu" <xufeng.liu.ietf@gmail.com> Fri, 06 October 2017 21:12 UTC

Return-Path: <xufeng.liu.ietf@gmail.com>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE24013239C; Fri, 6 Oct 2017 14:12:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.8
X-Spam-Level:
X-Spam-Status: No, score=-0.8 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, 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 TBX8KHdKPMLO; Fri, 6 Oct 2017 14:11:59 -0700 (PDT)
Received: from mail-lf0-x22d.google.com (mail-lf0-x22d.google.com [IPv6:2a00:1450:4010:c07::22d]) (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 0343D1320C9; Fri, 6 Oct 2017 14:11:58 -0700 (PDT)
Received: by mail-lf0-x22d.google.com with SMTP id d17so21701502lfe.2; Fri, 06 Oct 2017 14:11:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:subject:date:message-id:mime-version:thread-index :content-language; bh=eAmU8px+TdU1tOOqEXrguF2GKhJJ6dLH1M+iWwnv79I=; b=IaELiB8aKhrZwJQRT9d6ohTItSMGGuwwSsuFPF2kVCjpoNikh4P02Vtz06Twg/29bh LM/o7a+1Kuc3yOrSBQZbQmalJiXbawIW7M25GnNos91lcSYLA9azE4KkHIJx/paGtuOF vBuwF4P39Ai164b92uo+tbRrjB+5J+Tqn0pGgy6MO/FQkzpjFVQlcJhuQUfF0PU+qcL4 UYYKyQuZZIkTefKC8C7IeWzMYnlGzDfs8ll34AtwV8YviDpzkSSAZqo5DBqB5ea0LUvP +GP4ehZ7OzJpZcDIWQZk/mCIiwVatfLhkqPKUpM/KeBnxf/VUsGQzVJ2oV7vJyDeANls zjfQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:date:message-id:mime-version :thread-index:content-language; bh=eAmU8px+TdU1tOOqEXrguF2GKhJJ6dLH1M+iWwnv79I=; b=RBNUWR/3zLR5OMHEIyyQp8fUorv5OI1HvTsfJNgJaohpEDzxvYNTq6Hp386QsVWLKd MnBxhCBJ5UjdNpiuF1oPdwceCkRhPhIoHRCcLkpn8dZlUjUUTWNgLoCsc0LaxlN+su1i ITrmNpDeK51dd/GCNhzPMye44H3dBFub56uLcxHTBDIf/ZVeZSJJ4E/QT495EkI+LVXf bK4+grWGSaMfMjFa0L7J4nAhIVND1Tf1137NXYXE8SYZmrmDlSJOkLfFIXvcvGS8d1pw fTW6HGWnH2zCRgVUDxqoq7Aq7Mx59+FTW2PBWKa8AvCyO8s94LTyCB/sOMrSIe3Y3vWC subQ==
X-Gm-Message-State: AMCzsaUCgeYWMojvQCfTQP4azoDD4/ZfhSRD/asKLjHHRsn8+GcboFKy M9xxZxTjy1l/NNNNlB28bDnb+ay9
X-Google-Smtp-Source: AOwi7QAZG3layFA11LPAuOmP4p+JkMBDaw+cazWloT5UPtq0AZFdhr6yhfQtGCtIzKJVf+UIXPJ/RA==
X-Received: by 10.25.210.211 with SMTP id j202mr1398100lfg.8.1507324316538; Fri, 06 Oct 2017 14:11:56 -0700 (PDT)
Received: from xliuus (wsip-98-191-72-170.dc.dc.cox.net. [98.191.72.170]) by smtp.gmail.com with ESMTPSA id l14sm425137lfb.7.2017.10.06.14.11.55 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 06 Oct 2017 14:11:55 -0700 (PDT)
From: Xufeng Liu <xufeng.liu.ietf@gmail.com>
To: netconf@ietf.org, 'NetMod WG' <netmod@ietf.org>
Date: Fri, 06 Oct 2017 17:11:52 -0400
Message-ID: <033601d33ee7$bd359810$37a0c830$@gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0337_01D33EC6.3624BB60"
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AdM+52gw6QWX/3ijR4GeNhdOmHSt/g==
Content-Language: en-us
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/7nIt613SBwib1ovb-J-2mU4c8Q8>
Subject: [netmod] Retrieving Information Pointed by leafref
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 06 Oct 2017 21:12:01 -0000

During the design team discussion for TE and MPLS YANG modeling, we have
received a request from implementers: How to minimize the number of
NETCONF/RESTCONF RPCs to improve operation efficiency? Especially for the
case when the operator or client software needs to retrieve the object
contents pointed by a leafref.

For example, given the following simplified TE tunnel model,

+--rw te

    +--rw explicit-paths

    |  +--rw explicit-path* [name]

    |     +--rw name                      string

    |        +--rw explicit-route-object* [index]

    |           +--rw index                   uint32

    |           +--rw explicit-route-usage?   identityref

    +--rw tunnels

    |  +--rw tunnel* [name]

    |  |  +--rw name                   string

    |  |  +--rw paths

    |  |  |  +--rw path* [name]

|  |  |     +--rw explicit-path?  ->
../../../../../explicit-paths/explicit-path/name

 

when the client tries to retrieve a tunnel's information based on the tunnel
name, the "get" operation returns a list of leafref's pointing to the paths
of the tunnel. The client needs to issue at least one more "get" operation
to retrieve the path information about the given tunnel. The request is to
combine these two operations into one.

In the RDBMS SQL world, "join" can be used when SQL "select" is performed,
but NETCONF/YANG currently does not have this capability.

We'd like to ask whether such a request is considered reasonable.

If the request is reasonable, the next question is how to proceed. This
seems to be a protocol issue rather than YANG modeling issue. Is it
acceptable to add a new operation to achieve such a <get-data> operation
with expanded leafref's?

Comments and suggestions are appreciated.

Thanks,

- Xufeng