Re: [netmod] Adding system configuration to running [was: Re: Comments on NMDA-04]

Andy Bierman <andy@yumaworks.com> Thu, 14 September 2017 21:27 UTC

Return-Path: <andy@yumaworks.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 1D71313208E for <netmod@ietfa.amsl.com>; Thu, 14 Sep 2017 14:27:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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=yumaworks-com.20150623.gappssmtp.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 Q5F42LNh5AYB for <netmod@ietfa.amsl.com>; Thu, 14 Sep 2017 14:27:17 -0700 (PDT)
Received: from mail-lf0-x22c.google.com (mail-lf0-x22c.google.com [IPv6:2a00:1450:4010:c07::22c]) (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 C92EA120724 for <netmod@ietf.org>; Thu, 14 Sep 2017 14:27:16 -0700 (PDT)
Received: by mail-lf0-x22c.google.com with SMTP id q132so618258lfe.5 for <netmod@ietf.org>; Thu, 14 Sep 2017 14:27:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=EfQ1OOmStXdkXJH7J7FO9NS2id2mlrQP4ErKMAhjeV0=; b=wWQ4kTgQBUcA3b6ihzRRLZmwf0fYv/8I76gukldctS3j1nee50uoY+wE5uQRKCA6Dj ikGrNgAgrwOn5cfhfu9EPnSKkHShw66E5rj0ubtMlO8wCBp+2NUCgmUEYwdOnNB+ARnP /0MIZbX9WgI8g8AuOThaQlMXPPfGeI0QUtZQo9PD9/XvhYqJu8KQJ6yTEAO9HxqqEPzG sWAnv4gRE9cSNphPAHPypDTRFihX/m+fjPUU12LSx7MHK7BFUOLx2ruwnE93OtqUNYz/ 3WAU7nTf5NNBcJ6MfvDipYbApRWdMCA4vaFnjgzOUtPImq6nsl4dvCEZCaByfA4GxsQ/ yqdA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=EfQ1OOmStXdkXJH7J7FO9NS2id2mlrQP4ErKMAhjeV0=; b=NlSKRGtHzeuaOM88H0DIGQ16EVFl7AvE5/h4Fqf9dT3pAYCPjo2Lobu5HRlCMtPZKQ ixPJKUAP9hsffPmgw6BOKKpUaVu01bNZzLeNnNVRW9hIrRDibECBbFRxytWNkdHXR5gc Nfrmw2aNz5D7r3CMNKFgSHVu1nXnwOHWonZFJZI372UWmlHvHrzOYVIyBtzEIVRLoWQ6 aC1OEh69WpJFRNePT6rGE6xJYFzU3rpPOhVMjP29zPnYq3AJWilrnJa/bdyZAP20SvCf sfePtC03tDqZYauGXYccZVSSHBAEr1ejl0QbI+NnizyVbGWkg3DzQtF/U5vMZPojfof2 2cbQ==
X-Gm-Message-State: AHPjjUijFYYf45HWQkHnfBnt7EZZHDUnrvRVtfN//cFmLPvZW4Y1SxHZ 9jN9yv+Va0inS1fd1QwYok+s9cqYDQByEpDUhyrDOA==
X-Google-Smtp-Source: AOwi7QBoTGkSHssxdpXH9vMtVg8AdqKlM3CYdUpmZ6deaPfz6CuPR1UgNB8eBHp/IBrJ/n+HY9s6/sbfSzlDqlBZZGk=
X-Received: by 10.25.22.228 with SMTP id 97mr8704075lfw.205.1505424434753; Thu, 14 Sep 2017 14:27:14 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.25.18.41 with HTTP; Thu, 14 Sep 2017 14:27:14 -0700 (PDT)
In-Reply-To: <DF1AFB0F-53CB-40D2-B46F-2E5166705573@juniper.net>
References: <9ec6b2e4-36a7-87e6-59fa-828855235835@ericsson.com> <20170914.163239.143365521945928900.mbj@tail-f.com> <4ce3efcd-6e88-9390-1241-21fb89985a9a@ericsson.com> <4dc2014b-0355-ac0b-f9a0-06a2d73033c4@cisco.com> <CABCOCHQ64DUwH=4FHSDoxbSbugoo-OyrXDwq5_Evcrk+CjA43g@mail.gmail.com> <DF1AFB0F-53CB-40D2-B46F-2E5166705573@juniper.net>
From: Andy Bierman <andy@yumaworks.com>
Date: Thu, 14 Sep 2017 14:27:14 -0700
Message-ID: <CABCOCHTeK0qccKBwq5HC0WnJD7WL=TX_mjNZVqihYcy9iWvaww@mail.gmail.com>
To: Kent Watsen <kwatsen@juniper.net>
Cc: Robert Wilton <rwilton@cisco.com>, "netmod@ietf.org" <netmod@ietf.org>
Content-Type: multipart/alternative; boundary="001a1140260cab85cc05592cf01b"
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/P6uQwxSRkPCIsB5j_OHpdk6qgtg>
Subject: Re: [netmod] Adding system configuration to running [was: Re: Comments on NMDA-04]
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: Thu, 14 Sep 2017 21:27:20 -0000

On Thu, Sep 14, 2017 at 1:30 PM, Kent Watsen <kwatsen@juniper.net> wrote:

>
>
>
>
>
>
> > I agree with Balazs that system-created nodes in running are quite
> common and
>
> > the vendors doing it have no intention of changing it.
>
>
>
> Of course, what else were they going to do pre-NMDA…and also before
> require-instance
>
> false?  Green-field deployments wouldn't be encumbered with
> backwards-compatibility.
>
> Existing implementations are in a bind, but I'd recommend following
> nmda-guidelines.
>
>
>


This might break non-NMDA clients expecting to see the system-created config
in retrieval responses. I think vendors will decide their own transition
plans
and decide how much disruption at once is OK.



> For UC1: the loopback would only show in <operational> (as an applied
> instance of a
>
> config true leaf), and the leafref would be require-instance false.  When
> committing
>
> configuration that referenced loopback, the server sees that the
> referenced leaf is not in
>
> <running>/<intended>, but it could see that it is or is-not in
> <operational>.  And, if it
>
> is not in <operational>, the server might return a warning to the client,
> or not, assuming
>
> the  client will use other mechanisms to discover what configuration was
> not applied.
>
>
>
> For UC2: similar response.  The server could return a warning (e.g., a
> synchronous
>
> update) or the client can discover the unapplied config afterwards using
> other
>
> mechanisms.
>
>
>
>
>
> > If the added nodes need to be saved in non-volatile storage then then
> definitely
>
> > belong in <running>.
>
>
>
> Neither of Balazs's use-cases regard persisted data, at least I didn't
> read it that way.
>
>
>
>
>
> > IMO the architecture is rather opaque wrt/ the interactions between
> datastores,
>
> > especially the interactions between <running> and <intended>. Now it not
> only
>
> > prunes inactive nodes, it adds system nodes?
>
>
>
> A template in <running> could be flattened, which has the apparent
> side-effect
>
> of creating nodes, but not any nodes, just those per the input from
> <running>.
>
> As the draft says: <intended> does not persist across reboots; its
> relationship
>
> with <running> makes that unnecessary.   Generically speaking, <running>
>
> can contain processing instructions that are consumed at commit time to
>
> simultaneously create the <intended> view, and these PIs are the only thing
>
> that can cause a deviation between the two datastores.
>
>
>
>
>
> > Maybe it is too early for NMDA to be making lots of rules about how
>
> > YANG works with new (and unimplemented) datastores.
>
>
>
> Juniper has the equivalent of <intended> already.  I think others said
> they had
>
> something like it as well.
>
>
>
>
>

If I can only do YANG validation on expanded templates in <intended>, does
that mean
it is impossible to do YANG validation on the templates themselves in
<running>?
The template subtree can only use YANG constraints on external structures
in <intended>
and not refer to itself in anyway (in <running>)?

The RD draft sure has a lot of normative details for something that does
not use RFC 2119
terminology at all. I didn't know a Standards Track document could omit
these terms.
Architecture documents are usually Informational.

IMO the RD draft should not mention YANG or XPath at all.
That should be moved to an update to RFC 7950.
Those parts need more work anyway. The ARCH can move forward
without any dependence on YANG details.



> Kent // contributor
>
>
>
>
>

Andy