Re: [netmod] revised-datastores and commonality of schemas

Robert Wilton <rwilton@cisco.com> Fri, 03 November 2017 09:39 UTC

Return-Path: <rwilton@cisco.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 0502913FD31 for <netmod@ietfa.amsl.com>; Fri, 3 Nov 2017 02:39:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.501
X-Spam-Level:
X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 mHPENXSE651i for <netmod@ietfa.amsl.com>; Fri, 3 Nov 2017 02:39:19 -0700 (PDT)
Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93ECE13FD2D for <netmod@ietf.org>; Fri, 3 Nov 2017 02:39:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2281; q=dns/txt; s=iport; t=1509701958; x=1510911558; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=NCgdpcZNT3T06Mq+5IBXxOHqWxfc/Mzi2Ws+cqJdNOo=; b=UNzbnqY39IARykqRMPR2F7nxpL+PnqB95iSJspBRg4cJecmixg5rNLWK Wrk2yrRzU8vDwDh1MZQ0q2kPl6NHnxwrRfcOh92NS/pv/Kd+w86k/+jNe evldvCsgl1Iz47Np0eqBqYIqYZNZ4ty2Wy6gQTz+dpaFkPbcEA7qiyCN2 M=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CZAAABOPxZ/xbLJq1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBhQaEJIofdI9+JpZFghEKhTsChRQYAQEBAQEBAQEBayiFHgEFIw8?= =?us-ascii?q?BBUEQCxgCAiYCAlcGDQgBAYofqCGCJ4sRAQEBAQEBAQEBAQEBAQEBAQEhgQ+CH?= =?us-ascii?q?4NaghILgnaIJoJiBZkGiQiUfAKLdoc8jimHbYE5HziBbDQhCB0Vgy6EXkGNGwE?= =?us-ascii?q?BAQ?=
X-IronPort-AV: E=Sophos;i="5.44,338,1505779200"; d="scan'208";a="42028"
Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 03 Nov 2017 09:39:16 +0000
Received: from [10.63.23.76] (dhcp-ensft1-uk-vla370-10-63-23-76.cisco.com [10.63.23.76]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id vA39dG7Z028784; Fri, 3 Nov 2017 09:39:16 GMT
To: Phil Shafer <phil@juniper.net>, "Sterne, Jason (Nokia - CA/Ottawa)" <jason.sterne@nokia.com>
Cc: "netmod@ietf.org" <netmod@ietf.org>
References: <201711022131.vA2LVRjs044715@idle.juniper.net>
From: Robert Wilton <rwilton@cisco.com>
Message-ID: <71639489-a7d3-a5a2-4634-f539fe8877bb@cisco.com>
Date: Fri, 3 Nov 2017 09:39:16 +0000
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <201711022131.vA2LVRjs044715@idle.juniper.net>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/7ew2Rf-rz4o9VgcfWE4FRQWWnfQ>
Subject: Re: [netmod] revised-datastores and commonality of schemas
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, 03 Nov 2017 09:39:20 -0000

I agree.

I think that a configuration template is just another form of 
configuration, and hence would expect that the template itself appear in 
candidate, startup, running, intended, operational.

There could also be "system templates" that are not directly 
configurable, and do not appear in configuration (e.g. I think that a 
system defined Loopback0 interface could be thought to be part of a 
"system template").  E.g. basically just configuration that the system 
always merges in from running to intended.  Today, I would not expect to 
"see" these system templates, only the affect of them in <intended> and 
<operational>.

Thanks,
Rob


On 02/11/2017 21:31, Phil Shafer wrote:
> "Sterne, Jason (Nokia - CA/Ottawa)" writes:
>> The <running> DS needs to have both the template itself in the schema as well as
>> whatever nodes are used to hold 'exploded' data.  But what about intended and
>> operational ?
> For JUNOS, we carry both the raw and expanded views, though nothing
> in JUNOS is looking at the raw data outside of the UI code.  But we
> carry it, so that scripts can access this information and find the
> original "intent" for config.
>
> For example, if my interface template looked like:
>
> interfaces {
>      apply-macro so-0/0/0 {
>          inet-address 10.3.2.1/30;
>          role customer-facing;
>      }
> }
>
> and then my commit script turned this into traditional JUNOS
> config, like:
>
> interfaces {
>      so-0/0/0 {
>          unit 0 {
>              family inet {
>                  address 10.3.2.1/30;
>                  filter customer-facing;
>               }
>               family mpls;
>               family iso;
>          }
>      }
> }
> protocols {
>      bgp {
>          group customer-facing {
>              peer 10.3.2.2 {
>                  local-address 10.3.2.1;
>                  policy customer-facing;
> ...
>
> And whatever else "customer-facing" means.
>
> Both sets of config will be in <intended> and <operational> so that
> when I find an interface that's down, I can look (in <operational>)
> at the original apply-macro and see the role of the interface to know
> how loud an alarm I should be raising.
>
> Thanks,
>   Phil
> .
>