Re: [netmod] Opstate solutions discussions: update and request for WGinput

[Andy Bierman <[e-mail]>]

On Fri, Jun 17, 2016 at 11:22 AM, Lou Berger <[e-mail]> wrote:

> Tom,
>
>     Thanks for the perspective.  I'm a little unsure if you're expecting
> a response or just making a statement, so if you're looking for
> something specific and don't see it below -- please let me know.
>
> On 6/17/2016 11:15 AM, t.petch wrote:
> > Lou
> >
> > By now, 17th June, I see solid support for one option but only see
> > comments from a somewhat small number of participants
> This is true, and I've heard privately that some more may/should be
> forthcoming.
>
> > The majority of the authors of the 172 YANG files I have in an
> > archive are probably unaware of this discussion and yet some at least
> > will be affected.  What concerns me is that history might be repeating
> > itself.  In a sense, this discussion is about the original proposals for
> > NETCONF and YANG not meeting current requirements which
> > may be because there has mostly been a limited number of
> > participants in netmod discussions.
>
> So two points on this:
> - Today is different in that there are a great number of players
> using/looking to YANG at the moment --- so I think we have more lurkers
> out there than you'd expect.
>
> - The fact that 172 documents (and that's just in the IETF) would be
> impacted by option (A) is exactly why we think it's the wrong way to go.
> Think about if we came up with a solution that requires each modeler to
> build their definitions a fixed way how this would be
> socialized/enforced.  Now think about doing that in other SDOs.
>
>
Not to mention all the vendor defined YANG modules.

IMO this has always been a protocol issue.
The state of the data depends on the interaction model and that depends on
the protocol.
E.g., how does confirmed-commit factor into the state machine?
The config may be applied but also temporary, pending confirmation.

What if a YANG protocol mandated that <ok> means applied, not just intended?
That interaction model would not need separate datastores for intended vs.
applied.
(One solution approach is to update NETCONF to provide this interaction
model.)


Andy


> I was struck by Dale's recent, brilliant review of 6020bis because it
> > came from a fresh angle and brought up nagging concerns that I had had
> > but had not been able to articulate.  With a wider audience, similar
> > comments might have been made much earlier to the advantage
> > of YANG (perhaps even about RFC6020).
> >
> > In the same vein, there is NETCONF.  Juergen's I-D, which I see finding
> > favour, could be said to cut the ground from under NETCONF (well, I
> > would).  RFC6241 says
> > " Configuration data is the set of writable data that is required to
> >    transform a system from its initial default state into its current
> >    state.  State data is the additional data on a system that is not
> >    configuration data such as read-only status information and collected
> >    statistics.  "
> >
> > The proposed 'intended' in the I-D is (ct, ro).  It is ct, configuration
> > true, so it is configuration data.  It is ro, read only, so it is
> > clearly not
> > configuration data.  Without changing RFC6241, I cannot reconcile this.
> It's just a ro version/view of the config data.  I'm not sure why this
> is problematic.  Perhaps I'm just missing something.
>
> > So I see RFC6241 being changed; can anyone reading the RFC understand it
> > any more?  And yet the I-D makes no mention of this change to
> > NETCONF nor have I seen any discussion on the netconf list.
> >
> > Stimulated by posts to the I2RS list, perhaps also a trigger for
> > Juergen's I-D, I wrote up my own summary of the current state of
> > datastores but I called it draft-tp-netconf-datastore because I see
> > NETCONF
> > currently telling us almost all that we know about datastores; YANG 1.0
> > adds very little.  For me, NETCONF should be the starting point.
> The first question is deciding on an approach (A vs B), the second
> question is on the details of the selected option.  If we move forward
> with B, I think which WG does the data store work is a fine topic to
> consider.  But we (netmod)  first need to close on A vs B -- which will
> be easy if there are no new comments in short order.
>
> Lou
> > Tom Petch
> >
> > ----- Original Message -----
> > From: "Lou Berger" <[e-mail]>
> > To: "netmod WG" <[e-mail]>
> > Cc: <[e-mail]>
> > Sent: Tuesday, June 07, 2016 3:19 PM
> >
> >> 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
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/netmod
> >
>
>
> _______________________________________________
> netmod mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netmod
>