Re: [Rtg-yang-coord] [i2rs] Fwd: [netmod] Opstate solutions discussions: update and request for WG input

"Susan Hares" <shares@ndzh.com> Thu, 09 June 2016 13:48 UTC

Return-Path: <shares@ndzh.com>
X-Original-To: rtg-yang-coord@ietfa.amsl.com
Delivered-To: rtg-yang-coord@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40B4B12D18C; Thu, 9 Jun 2016 06:48:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.738
X-Spam-Level: *
X-Spam-Status: No, score=1.738 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, RDNS_NONE=0.793] autolearn=no 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 sO2brF4jtOZG; Thu, 9 Jun 2016 06:48:52 -0700 (PDT)
Received: from hickoryhill-consulting.com (unknown [50.245.122.97]) (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 28D0812D09F; Thu, 9 Jun 2016 06:48:52 -0700 (PDT)
X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=174.124.192.86;
From: "Susan Hares" <shares@ndzh.com>
To: "'Martin Bjorklund'" <mbj@tail-f.com>
References: <63b1dc74-c60c-351d-8d6d-38c860a6476e@labn.net> <155301e8b20.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <00d301d1c1a0$3b12c8f0$b1385ad0$@ndzh.com> <20160608.194028.358336333232277992.mbj@tail-f.com>
In-Reply-To: <20160608.194028.358336333232277992.mbj@tail-f.com>
Date: Thu, 9 Jun 2016 09:48:56 -0400
Message-ID: <002b01d1c255$abc9e8c0$035dba40$@ndzh.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQH5OFvhp0hvxO8+SMw1aajlqpN6IwJELg8iAeYo0GEBXY3Csp9l+kNg
Content-Language: en-us
X-Authenticated-User: skh@ndzh.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-yang-coord/_gWmCm0dP2hmmpLTB6iruK1NTMY>
Cc: Rtg-yang-coord@ietf.org, bclaise@cisco.com, lberger@labn.net, i2rs@ietf.org, akatlas@gmail.com
Subject: Re: [Rtg-yang-coord] [i2rs] Fwd: [netmod] Opstate solutions discussions: update and request for WG input
X-BeenThere: rtg-yang-coord@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "\"List to discuss coordination between the Routing related YANG models\"" <rtg-yang-coord.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtg-yang-coord>, <mailto:rtg-yang-coord-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtg-yang-coord/>
List-Post: <mailto:rtg-yang-coord@ietf.org>
List-Help: <mailto:rtg-yang-coord-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtg-yang-coord>, <mailto:rtg-yang-coord-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 09 Jun 2016 13:48:53 -0000

Martin: 

I agree [4] and [5] provide possible architectures that ephemeral could fit
into as part of choice [B].  

Sue 
-----Original Message-----
From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Martin Bjorklund
Sent: Wednesday, June 08, 2016 1:40 PM
To: shares@ndzh.com
Cc: Rtg-yang-coord@ietf.org; bclaise@cisco.com; lberger@labn.net;
akatlas@gmail.com; i2rs@ietf.org
Subject: Re: [i2rs] [Rtg-yang-coord] Fwd: [netmod] Opstate solutions
discussions: update and request for WG input

Hi Sue,


"Susan Hares" <shares@ndzh.com>; wrote:
> In [4], the author states: 
> 
>    "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]"

[...]

> Therefore, the result of I2RS WG spending 2 years writing requirements 
> for the ephemeral data store that both option 2 documents "do not  
> match" the I2RS ephemeral requirements set.  [4] lumps ephemeral with 
> operational state.

I don't think this last sentence is correct.  Admittedly, the details about
ephemeral in [4] are not worked out (by design).  But the idea was not to
"lump ephemeral and operational state".  The idea was rather that the
content of ephemeral datastore(s) would interact with the applied config to
produce the resulting operational state.

If the WG agrees that B is the right way to go, we'll need to work out all
the details about how the ephemeral datastore(s) work.

The main point is that [4] (and [5]) provides an architecture into which
ephemeral datastores can fit.


/martin

_______________________________________________
i2rs mailing list
i2rs@ietf.org
https://www.ietf.org/mailman/listinfo/i2rs