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

Lou Berger <lberger@labn.net> Wed, 08 June 2016 16:23 UTC

Return-Path: <lberger@labn.net>
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 51EB112D093 for <rtg-yang-coord@ietfa.amsl.com>; Wed, 8 Jun 2016 09:23:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.002
X-Spam-Level:
X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.net
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 pmFm6_wdPkEd for <rtg-yang-coord@ietfa.amsl.com>; Wed, 8 Jun 2016 09:23:35 -0700 (PDT)
Received: from gproxy2-pub.mail.unifiedlayer.com (gproxy2-pub.mail.unifiedlayer.com [69.89.18.3]) by ietfa.amsl.com (Postfix) with SMTP id 5441F12D1D2 for <Rtg-yang-coord@ietf.org>; Wed, 8 Jun 2016 09:23:35 -0700 (PDT)
Received: (qmail 3999 invoked by uid 0); 8 Jun 2016 16:23:35 -0000
Received: from unknown (HELO cmgw4) (10.0.90.85) by gproxy2.mail.unifiedlayer.com with SMTP; 8 Jun 2016 16:23:35 -0000
Received: from box313.bluehost.com ([69.89.31.113]) by cmgw4 with id 4GPV1t01N2SSUrH01GPYr1; Wed, 08 Jun 2016 10:23:34 -0600
X-Authority-Analysis: v=2.1 cv=ecGuId0H c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=N659UExz7-8A:10 a=-NfooI8aBGcA:10 a=uEJ9t1CZtbIA:10 a=pD_ry4oyNxEA:10 a=48vgC7mUAAAA:8 a=wU2YTnxGAAAA:8 a=_YrKmtLnOJmTjYVyYW4A:9 a=6XKu0j9-T9O7taiO:21 a=7DWPM4YPNewJAEty:21 a=pILNOxqGKmIA:10 a=aHrNv8WqsBEA:10 a=972hS-PGyNsA:10 a=w1C3t2QeGrPiZgrLijVG:22 a=Yz9wTY_ffGCQnEDHKrcv:22
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version :Date:Message-ID:From:Cc:References:To:Subject; bh=Yxbqurd2owgDW4dAn0/av2uqoXMqqoezr8AEqNAFWOw=; b=CE/Ww/9JFI8GLCQ7W74dwbiDUv z4LT8R2S7ueXeATjl7QGSghfnMgw6m0vPMyxqpLh1uFcHwgdkHOb9OO69TUm6ZgJEX2r7FF7xDG5K O5yJ5+YPlIjx3g3R/i/zKbtis;
Received: from box313.bluehost.com ([69.89.31.113]:48005 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.86_2) (envelope-from <lberger@labn.net>) id 1bAgGP-0006Cx-Ev; Wed, 08 Jun 2016 10:23:29 -0600
To: Susan Hares <shares@ndzh.com>, Rtg-yang-coord@ietf.org
References: <63b1dc74-c60c-351d-8d6d-38c860a6476e@labn.net> <155301e8b20.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <00d301d1c1a0$3b12c8f0$b1385ad0$@ndzh.com>
From: Lou Berger <lberger@labn.net>
Message-ID: <9fbe631a-6a93-44fc-da02-7b2dd9827ddb@labn.net>
Date: Wed, 8 Jun 2016 12:23:23 -0400
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1
MIME-Version: 1.0
In-Reply-To: <00d301d1c1a0$3b12c8f0$b1385ad0$@ndzh.com>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net}
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-yang-coord/R9JZ8NycMPWgcpgVWm2SSHJr7nk>
Cc: 'Benoit Claise' <bclaise@cisco.com>, i2rs@ietf.org, 'Alia Atlas' <akatlas@gmail.com>
Subject: Re: [Rtg-yang-coord] 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: Wed, 08 Jun 2016 16:23:37 -0000

Sue,

I think you're looking a step beyond the scope of decision we're
considering now. This is a fine thing, and certainly the right thing to
be thinking about from the I2RS (or any other WG working on YANG models
that is considering operational state for that matter) perspective.

The decision at hand is to choose between directions A and B.  I think
you are saying you that you like direction B but that the details aren't
sufficient for your (WG's) needs.  Is this correct?

If so, then I think you're point is that [4] and [5] need work.  We
agree with this statement and we believe consistent with the statement in B:

    -- and that the WG needs to
       formalize an opstate solution based on the approach
       discussed in [4] and [5].

So, once the WG closes on direction B (before Berlin), the WG can then
start discussing details of the WG's version of [4] and [5] -- and
issues on ephemeral support makes sense to discuss then if they still
haven't been addressed.   Of course discussion on the individual drafts
don't need to wait for the decision on basic direction.

Make sense?

Lou

On 6/8/2016 12:10 PM, Susan Hares wrote:
> Lou: 
>
> Thank you for your work on the two options.  I'd like to comment on the
> following statement in your message statement, and reference a few things in
> [4] and [5] regarding ephemeral state: 
>
> You state: 
> "  2) Model OpState using a revised logical datastore definition
>        as introduced in [4] and also covered in [5]. There is
>        also a variant of this that we believe doesn't significantly
>        impact this choice.  
>        With this approach, model definitions need no explicit
>        changes to support applied configuration."
>
> 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]"
>
> In [5], the author states: 
>
> "5.5.  Ephemeral Configuration Datastore (Optional)
>    This document does not intend to formally define an Ephemeral
>    Configuration Datastore.  In particular, it must be noted that the
>    ephemeral configuration datastore described here does not match that
>    described in version -09 of draft-ietf-i2rs-ephemeral-state
>    [I-D.ietf-i2rs-ephemeral-state].  Instead, it describes conceptually
>    how such a datastore (restricted to configuration only) might fit
>    into a conceptual refined datastore model."
>
> 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.  [5] provides an ephemeral architecture closer to I2RS ephemeral
> requirements, but does not understand that draft-ietf-i2rs-ephemeral-state
> is a requirements document.    Your statement " With this approach, model
> definitions need no explicit changes to support applied configuration"
> cannot be true if you consider the I2RS data models (RIB, topology). 
>
> How is option (2) a reasonable design for ephemeral state?  I have spent the
> last week answering questions to Juergen [4] on the I2RS ephemeral state.
> After our discussion, he did not have any specific suggestions to change
> these requirements
> (https://www.ietf.org/mail-archive/web/i2rs/current/msg03688.html).  
>
> Can I have an option 2b that considers ephemeral state based on the
> requirements listed by I2RS? 
>
>  Sue Hares  
>  I2RS WG-chair 
>
> -----Original Message-----
> From: Rtg-yang-coord [mailto:rtg-yang-coord-bounces@ietf.org] On Behalf Of
> Lou Berger
> Sent: Wednesday, June 08, 2016 9:06 AM
> To: Rtg-yang-coord@ietf.org
> Subject: [Rtg-yang-coord] Fwd: [netmod] Opstate solutions discussions:
> update and request for WG input
>
> FYI this decision is likely to have some impact on models under development,
> including in the routing area. Comments on the message itself should go to
> netmod.
>
> Lou
>
>
> --- Forwarded message ---
> From: Lou Berger <lberger@labn.net>;
> Date: June 7, 2016 10:20:23 AM
> Subject: [netmod] Opstate solutions discussions: update and request for WG
> input
> To: netmod WG <netmod@ietf.org>;
> CC: netmod-chairs@ietf.org
>
> All,
>
> We want to provide an update based on the off line discussions related to
> OpState Solutions that we have been having and solicit input from the WG.
>
> All authors of current solution drafts [1,2,3] together with those who
> helped conduct the solutions analysis* were invited to the these discussions
> -- with the objective of coming up with a single consolidated proposal to
> bring to the WG. (I/Lou acted as facilitator as Kent and Juergen were and
> are involved with the technical details.)
>
> The discussions have yielded some results but, unfortunately, not a single
> consolidated proposal as hoped, but rather two alternate directions -- and
> clearly we need to choose one:
>
>     1) Adopt the conventions for representing state/config
>        based on Section 6 of [1].
>
>        From a model definition perspective, these conventions
>        impact every model and every model writer.
>
>     2) Model OpState using a revised logical datastore definition
>        as introduced in [4] and also covered in [5]. There is
>        also a variant of this that we believe doesn't significantly
>        impact this choice.
>
>        With this approach, model definitions need no explicit
>        changes to support applied configuration.
>
> >From a technology/WG standpoint, we believe an approach
> that doesn't impact every model written (i.e., #2) is superior.
> The counterpoint to this is that the conventions based approach (i.e., #1)
> is available today and being followed in OpenConfig defined models.
>
> We would like to hear opinions on this from the WG before declaring one of
> the following as the WG direction:
>
>     A) models that wish to support applied configuration MUST
>        follow conventions based on [1] -- and the WG needs to
>        formalize these conventions.
> or
>     B) no explicit support is required for models to support
>        applied configuration -- and that the WG needs to
>        formalize an opstate solution based on the approach
>        discussed in [4] and [5].
>
> We intend to close on this choice before Berlin.
>
> Thank you,
> Lou (and co-chairs)
>
> [1] https://tools.ietf.org/html/draft-openconfig-netmod-opstate-01
> [2] https://tools.ietf.org/html/draft-kwatsen-netmod-opstate-02
> [3] https://tools.ietf.org/html/draft-wilton-netmod-opstate-yang-02
> [4] https://tools.ietf.org/html/draft-schoenw-netmod-revised-datastores-00
> [5] https://tools.ietf.org/html/draft-wilton-netmod-refined-datastores-00
> * - Chris H. and Acee L.
>
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>
>
>
> _______________________________________________
> Rtg-yang-coord mailing list
> Rtg-yang-coord@ietf.org
> https://www.ietf.org/mailman/listinfo/rtg-yang-coord
>
>