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

Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> Tue, 31 May 2016 14:25 UTC

Return-Path: <j.schoenwaelder@jacobs-university.de>
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 4159812D17E for <i2rs@ietfa.amsl.com>; Tue, 31 May 2016 07:25:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.626
X-Spam-Level:
X-Spam-Status: No, score=-5.626 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426] 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 ATrIzfsHko_i for <i2rs@ietfa.amsl.com>; Tue, 31 May 2016 07:25:50 -0700 (PDT)
Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 68DF912B00C for <i2rs@ietf.org>; Tue, 31 May 2016 07:25:50 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id B57BC8DD; Tue, 31 May 2016 16:25:48 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id m0ZIsKVqOgSL; Tue, 31 May 2016 16:25:45 +0200 (CEST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Tue, 31 May 2016 16:25:46 +0200 (CEST)
Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id D7C5C20054; Tue, 31 May 2016 16:25:46 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id zDx6LjO5-iYn; Tue, 31 May 2016 16:25:44 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id E785C20062; Tue, 31 May 2016 16:25:40 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id B81B33AFE399; Tue, 31 May 2016 16:25:40 +0200 (CEST)
Date: Tue, 31 May 2016 16:25:40 +0200
From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
To: Susan Hares <shares@ndzh.com>
Message-ID: <20160531142540.GA22420@elstar.local>
Mail-Followup-To: Susan Hares <shares@ndzh.com>, 'Jeffrey Haas' <jhaas@pfrc.org>, i2rs@ietf.org, 'Benoit Claise' <bclaise@cisco.com>, 'Alia Atlas' <akatlas@gmail.com>
References: <000601d1bad5$70523090$50f691b0$@ndzh.com> <20160531063840.GA21289@elstar.local> <00d501d1bb45$0da83500$28f89f00$@ndzh.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <00d501d1bb45$0da83500$28f89f00$@ndzh.com>
User-Agent: Mutt/1.6.0 (2016-04-01)
Archived-At: <http://mailarchive.ietf.org/arch/msg/i2rs/O4OD6vBeC2PnRbTNZWRy0sxdRhI>
Cc: 'Jeffrey Haas' <jhaas@pfrc.org>, i2rs@ietf.org, 'Benoit Claise' <bclaise@cisco.com>, 'Alia Atlas' <akatlas@gmail.com>
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
Reply-To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
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 14:25:54 -0000

On Tue, May 31, 2016 at 10:02:17AM -0400, Susan Hares wrote:
> Juergen: 
> 
>  
> 
> Thank you for the second response.    The questions were on version 8 of the
> draft.  Jeff wanted to review version 8 before posting - so I delayed
> posting of version 8 until this morning.    I've answered your questions
> based on version 08. 
> 
>  
> 
> I think you understood that the ephemeral datastores defined by i2RS are not
> what you defined in draft-schoenw-netmod-revised-datastores-00: 
> 
>    o  The model foresees ephemeral datastores that are by definition not
>       part of the persistent configuration of a device.  These ephemeral
>       datastores are considered to interact with the rest of the system
>       like any other control-plane mechanisms (e.g., routing protocols,
>       discovery protocols).  [XXX Note that this is different from what
>       is described in some of the I2RS documents.  XXX]
> 
> The difference is that I2RS defines ephemeral configuration and ephemeral
> operational state.  You see this in all of the I2RS data modules.  I have
> augmented your diagram with the proposed I2RS datastore. 
> 
> 
>                     +------------+
>                     | <intended> |  //  Subject to validation
>                     | (ct, ro)   | //   e.g., missing resources or delays
>                     +------------+   // Here I2RS ephemeral configuration
> fits 
>                           |         //  so missing resources/delays can be
> handled
>                           v
>                     +------------+
>                     | <applied>  |    - here I2RS defines ephemeral 
>                     | (ct, ro)   |      configuration data store 
>                     +------------+
>                           |         // e.g., autodiscovery of values
>                           v
>           +--------------------------------+
>           | <operational-state>            |<-- control plane and
>           | (ct + cf, ro)                  |    ephemeral datastores
> 
>                       +--------------------------------------------------+
> 
>  
> 
> Your definitions ignored the WG requirements and the existing discussions.
> Is there a reason why?  I2RS follows the break between operational state and
> configuration data store. 
>

There needs to be _one_ architectural model. I may be ignorant but we
have to look at how things fit together. What you are drawing is
ignoring for instance the fact that <intended> is the subject of
configuration validation while I2RS explicitly states that ephemeral
is not part of configuration validation. So your model is not a
workable solution either.
  
> o  configuration datastore: When modeled with YANG, a configuration
>       datastore is realized as an instantiated data tree with
>       configuration data.
>  
> o  Operational state data is a set of data that has been obtained by
>       the system at runtime and influences the system's behavior similar
>       to configuration data.  In contrast to configuration data,
>       operational state is transient and modified by interactions with
>       internal components or other systems via specialized protocols.
>  
> This document is proposed on May 12, 2016 and we have been working on I2RS
> for over 3 years.  You provided something that does not satisfy the
> requirements of the existing I2RS data models (prepared for over 18 months).
> 

Which I2RS requirements? Please be specific.

There needs to be _one_ architectural model for all the datastores
people to introduce in various places and it does not help to
complain. Please get down to the I2RS requirements that the above
proposal does not address. Make a better proposal. Iterate. There have
been quite a few calls related to the intended and applied datastore
discussions that are not taking place in I2RS land and as I said above
we need to come up with a common architectural model.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>