Re: [i2rs] Ephemeral State Requirements discussion

Jeffrey Haas <jhaas@pfrc.org> Thu, 02 June 2016 14:22 UTC

Return-Path: <jhaas@slice.pfrc.org>
X-Original-To: i2rs@ietfa.amsl.com
Delivered-To: i2rs@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6CC512D510 for <i2rs@ietfa.amsl.com>; Thu, 2 Jun 2016 07:22:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.328
X-Spam-Level:
X-Spam-Status: No, score=-3.328 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 nrBdVWAEnkUz for <i2rs@ietfa.amsl.com>; Thu, 2 Jun 2016 07:21:58 -0700 (PDT)
Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 6CBE512D140 for <i2rs@ietf.org>; Thu, 2 Jun 2016 07:21:58 -0700 (PDT)
Received: by slice.pfrc.org (Postfix, from userid 1001) id D15801E335; Thu, 2 Jun 2016 10:27:33 -0400 (EDT)
Date: Thu, 02 Jun 2016 10:27:33 -0400
From: Jeffrey Haas <jhaas@pfrc.org>
To: Susan Hares <shares@ndzh.com>, "'Joel M. Halpern'" <jmh@joelhalpern.com>, i2rs@ietf.org
Message-ID: <20160602142733.GU17462@pfrc.org>
References: <000601d1bad5$70523090$50f691b0$@ndzh.com> <20160531063840.GA21289@elstar.local> <026df5be-4a60-f340-60aa-d713a0e75c48@joelhalpern.com> <20160531184844.GB22928@elstar.local> <413ef504-49a8-2ba2-7fd4-582a41bd0ad0@joelhalpern.com> <20160531192729.GA23116@elstar.local> <005801d1bb7a$e7b2e440$b718acc0$@ndzh.com> <20160601091953.GD24118@elstar.local>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <20160601091953.GD24118@elstar.local>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: <http://mailarchive.ietf.org/arch/msg/i2rs/incQG01FVdqKH4UozxStF_D6Lqo>
Subject: Re: [i2rs] Ephemeral State Requirements discussion
X-BeenThere: i2rs@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "Interface to The Internet Routing System \(IRS\)" <i2rs.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/i2rs>, <mailto:i2rs-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/i2rs/>
List-Post: <mailto:i2rs@ietf.org>
List-Help: <mailto:i2rs-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/i2rs>, <mailto:i2rs-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 02 Jun 2016 14:22:01 -0000

Juergen,

On Wed, Jun 01, 2016 at 11:19:53AM +0200, Juergen Schoenwaelder wrote:
> On Tue, May 31, 2016 at 04:27:51PM -0400, Susan Hares wrote:
> > How does ephemeral sitting next to the <applied> data store provide
> > the ability to augment configuration with ephemeral configuration or
> > operational state with ephemeral operational state?
> 
> At the schema level, you will augment the schema tree. If the current
> separation of /foo and /foo-state would go away, this will likely get
> simpler (but this is orthogonal to the question how an <ephemeral>
> datastore conceptually interacts with the other datastores).
> 
> At the data tree level, there is a magic merging (+) function involved
> that takes configuration data from a configuration datastore and data
> from an ephemeral data store and produces the resulting operational
> state. The idea was to not further detail how this is achieved and
> instead treat an ephemeral datastore pretty much like any other
> control plane interface interacting with <operational state>.

While such a solution-space seems mostly right, I had been under the
impression that the interactions necessary for validation meant that
ephemeral needed to move up closer to the top of your diagram.

Note that I'm not saying I2RS requires validation, however the lack of
validation has been a contentious point in prior discussions.

To confirm my understanding, ephemeral configuration state in the model
you're proposing above is treated as operational state (the output of the
netconf <get> operation for config true elements)?

-- Jeff