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

Lou Berger <lberger@labn.net> Wed, 08 June 2016 19:27 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 770EB12B00B for <rtg-yang-coord@ietfa.amsl.com>; Wed, 8 Jun 2016 12:27:31 -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=unavailable 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 EjCKs7XewKkQ for <rtg-yang-coord@ietfa.amsl.com>; Wed, 8 Jun 2016 12:27:28 -0700 (PDT)
Received: from gproxy6-pub.mail.unifiedlayer.com (gproxy6-pub.mail.unifiedlayer.com [67.222.39.168]) by ietfa.amsl.com (Postfix) with SMTP id 8CCFA12D548 for <Rtg-yang-coord@ietf.org>; Wed, 8 Jun 2016 12:27:28 -0700 (PDT)
Received: (qmail 23171 invoked by uid 0); 8 Jun 2016 19:27:24 -0000
Received: from unknown (HELO cmgw2) (10.0.90.83) by gproxy6.mail.unifiedlayer.com with SMTP; 8 Jun 2016 19:27:24 -0000
Received: from box313.bluehost.com ([69.89.31.113]) by cmgw2 with id 4KTB1t01F2SSUrH01KTEoP; Wed, 08 Jun 2016 13:27:22 -0600
X-Authority-Analysis: v=2.1 cv=ff4+lSgF c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=IkcTkHD0fZMA:10 a=-NfooI8aBGcA:10 a=uEJ9t1CZtbIA:10 a=pD_ry4oyNxEA:10 a=wU2YTnxGAAAA:8 a=48vgC7mUAAAA:8 a=h1CNhEJjTAOSSbiXWbYA:9 a=XKglFbNVR357Agop:21 a=yK49gFaQljK2HJlX:21 a=QEXdDO2ut3YA:10 a=aHrNv8WqsBEA:10 a=972hS-PGyNsA:10 a=Yz9wTY_ffGCQnEDHKrcv:22 a=w1C3t2QeGrPiZgrLijVG: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=yXEcu2gseVYk/UjI5LpVKOE36p2AovIPkN6M/JtcIME=; b=jd4Ci1s/VbSx/dJ8eHGCxWwFb8 gpas7Xgif/lZt394YAW2t5e0JLR/9fTW9zaCYrwsMNAMDeloYrip5QnNNbDZ/EFip3xLPNETbd6Yv +WQJR+N9JV3R7rwzsc6g+1IPn;
Received: from box313.bluehost.com ([69.89.31.113]:48454 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.86_2) (envelope-from <lberger@labn.net>) id 1bAj8D-00009Y-7q; Wed, 08 Jun 2016 13:27:13 -0600
To: Andy Bierman <andy@yumaworks.com>
References: <63b1dc74-c60c-351d-8d6d-38c860a6476e@labn.net> <155301e8b20.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <00d301d1c1a0$3b12c8f0$b1385ad0$@ndzh.com> <9fbe631a-6a93-44fc-da02-7b2dd9827ddb@labn.net> <CABCOCHTY6pcW-RzXJsk6Ft2OFwCL2GwixAi_dH923noYKmXo0A@mail.gmail.com>
From: Lou Berger <lberger@labn.net>
Message-ID: <834c9a77-76e4-23b9-87e6-d28439e52bd2@labn.net>
Date: Wed, 8 Jun 2016 15:27:07 -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: <CABCOCHTY6pcW-RzXJsk6Ft2OFwCL2GwixAi_dH923noYKmXo0A@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
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/Z297AkJzIiD3t18fb8dyzXs1OUw>
Cc: "rtg-yang-coord@ietf.org" <Rtg-yang-coord@ietf.org>, Benoit Claise <bclaise@cisco.com>, Alia Atlas <akatlas@gmail.com>, Susan Hares <shares@ndzh.com>, "i2rs@ietf.org" <i2rs@ietf.org>
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 19:27:31 -0000

Andy, (Sue)

    Valid point -- either way the WG will get to Ephemeral *after* the
direction question is settled.

Lou


On 6/8/2016 1:39 PM, Andy Bierman wrote:
> Hi Lou,
>
> I would say 2 steps ahead.
> Step 1 seems to be to reconfirm the meeting room consensus from Yokohama
> (model-based vs. protocol-based)
>
> Step 2 is usually picking a starting point for a solution draft.
>
> Step 3 is when people can start detailed solution reviews.
>
> IMO [4] is a good starting point but there are many open issues that
> need to be resolved,
> possibly addressed in the other drafts.
>
>
> Andy
>
>
> On Wed, Jun 8, 2016 at 9:23 AM, Lou Berger <lberger@labn.net
> <mailto:lberger@labn.net>> wrote:
>
>     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
>     <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 <mailto: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 <mailto: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 <mailto:netmod@ietf.org>>
>     > CC: netmod-chairs@ietf.org <mailto: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 <mailto:netmod@ietf.org>
>     > https://www.ietf.org/mailman/listinfo/netmod
>     >
>     >
>     >
>     > _______________________________________________
>     > Rtg-yang-coord mailing list
>     > Rtg-yang-coord@ietf.org <mailto:Rtg-yang-coord@ietf.org>
>     > https://www.ietf.org/mailman/listinfo/rtg-yang-coord
>     >
>     >
>
>
>     _______________________________________________
>     Rtg-yang-coord mailing list
>     Rtg-yang-coord@ietf.org <mailto:Rtg-yang-coord@ietf.org>
>     https://www.ietf.org/mailman/listinfo/rtg-yang-coord
>
>