Re: [i2rs] I2RS Interim Meeting - June 1, 2016 - 10:00am - 11:00am - Topic: Ephemeral State Requirements

Jeffrey Haas <jhaas@pfrc.org> Tue, 31 May 2016 19:39 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 193B212D7F2 for <i2rs@ietfa.amsl.com>; Tue, 31 May 2016 12:39:33 -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 PT8yQ0gVFOnm for <i2rs@ietfa.amsl.com>; Tue, 31 May 2016 12:39:31 -0700 (PDT)
Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 986BB12D7F5 for <i2rs@ietf.org>; Tue, 31 May 2016 12:39:31 -0700 (PDT)
Received: by slice.pfrc.org (Postfix, from userid 1001) id 6E9F51E335; Tue, 31 May 2016 15:45:04 -0400 (EDT)
Date: Tue, 31 May 2016 15:45:04 -0400
From: Jeffrey Haas <jhaas@pfrc.org>
To: Susan Hares <shares@ndzh.com>, i2rs@ietf.org, 'Benoit Claise' <bclaise@cisco.com>, 'Alia Atlas' <akatlas@gmail.com>
Message-ID: <20160531194504.GM17462@pfrc.org>
References: <000601d1bad5$70523090$50f691b0$@ndzh.com> <20160531063840.GA21289@elstar.local> <00d501d1bb45$0da83500$28f89f00$@ndzh.com> <20160531142540.GA22420@elstar.local> <001401d1bb4e$cfaefd10$6f0cf730$@ndzh.com> <20160531171304.GA22857@elstar.local>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <20160531171304.GA22857@elstar.local>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: <http://mailarchive.ietf.org/arch/msg/i2rs/SU_Xq4eqo-hONp9_80GzxYb_q8s>
Subject: Re: [i2rs] I2RS Interim Meeting - June 1, 2016 - 10:00am - 11:00am - Topic: Ephemeral State Requirements
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: Tue, 31 May 2016 19:39:33 -0000

On Tue, May 31, 2016 at 07:13:04PM +0200, Juergen Schoenwaelder wrote:
> I understand YANG validation rules and I understand YANG's notion of
> configuration datastores. I do not think this matches your ephemeral
> configuration validation.

Prior working group discussion had suggested that bypassing validation (e.g.
constraints) may be required for sufficiently fast operations.  Obviously
this point has remained contentious.

The functional desire is sufficient speed out of configuration operations in
the ephemeral elements of the datastore.  If that can be done without
compromising on validation - or imposing certain considerations on the
structure of i2rs/ephemeral modules - I suspect that would satisfy the
working group.

> >     Ephemeral-REQ-01: I2RS requires ephemeral state; i.e. state that does
> >    not persist across reboots.  If state must be restored, it should be
> >    done solely by replay actions from the I2RS client via the I2RS
> >    agent.  Ephemeral state may consist of ephemeral configuration 
> >   or ephemeral operational state, or both.  
> > ========
> 
> So how is this broken? This is the only time 'ephemeral operational
> state' shows up in -09. So please elaborate whether this is by
> intention in order to express that 'ephemeral operational state' is
> something different than a subset of 'operational state' or even
> better please explain how you think 'ephemeral operational state'
> relates to 'operational state'.

I would suggest that we avoid talking about "ephemeral operational state".
While it's possible to discuss the context of such a thing existing as a
result of schema rules that config false nodes may be under nodes that are
both config true and ephemeral true (using our example keyword
modifications), I don't think calling it ephemeral operational state brings
too much to the conversation.

The one case for possible concern is that in the event the ephemeral
datastore is off-line is that such config false nodes may not be present.
However, this may be covered by other existing netconf mechanisms depending
on how the ephemeral datastore and related modules are instantiated in the
protocol.

> There are many datastores being proposed and at the end they all need
> to work together. Implementations can't support N different datastore
> models that are not aligned. I understand that this concern is not
> your prime problem since your focus is I2RS but please understand that
> other people are proposing other datastores and I do believe
> NETMOD/NETCONF needs to find agreement on a bigger architectural
> picture that addresses the various requirements and enables
> implementations that work in a predictable manner.

Some of the frustration comes from the discussion for ephemeral state having
been ongoing while the current operational state discussions have been
somewhat new.  

We agree that we need to have a unified datastore architecture.

-- Jeff