Re: [netmod] Closing on an OpState Solution Direction (was: Opstate solutions discussions: update and request for WG input)

[Lou Berger <[e-mail]>]

Anees,

    Thank you for all your effort and very informative and valuable
input on this and other topics! I do expect that we will fairly quickly
(in relative terms) move towards a solution and look forward to your,
and OpenConfig member's, continued and important participation in the
IETF.  On the OpState topic, I (we?) will be particularly interested in
your view on if the evolving solution meets your needs so that we can
minimize the cost of refactoring.

Thanks,
Lou
On 7/1/2016 1:13 PM, Anees Shaikh wrote:
> Lou, as we've discussed in the many working group calls on this topic
> and offline, the OpenConfig operator working group will continue to
> work with 'Option A', given there are already many models using it,
> several vendor implementations in progress, and also NMSes that are
> working today with this approach.  If and when the IETF arrives at a
> standard (based on Option B or otherwise), I expect we will review the
> work and the benefit of aligning with it.
>
> thanks.
> -- Anees
>
>
> On Fri, Jul 1, 2016 at 9:36 AM, Lou Berger <[e-mail]
> <mailto:[e-mail]>> wrote:
>
>     All,
>
>     It's time to make a consensus call on this topic, so that we can
>     all move on to defining a solution and aligning modules under
>     development. Based on the feedback received and the overall
>     discussions on the topic, we see that there is consensus to follow
>     a datastore based approach to supporting operational state, i.e.,
>     direction 'B'.
>
>     We will be asking the authors of [4] and [5] to review their
>     proposals (individual drafts) in Berlin, as well as to highlight
>     differences and suggest ways that their work could be
>     consolidated. Of course, others may also choose to submit their
>     own proposals. Given the importance of this work, we will be
>     looking to have active discussion on the topic both in Berlin and
>     on the list, with an objective of having a draft ready for
>     considerations as a WG document by the November IETF.
>
>     We have reviewed this decision with our AD and the NetConf chairs
>     and have agreed to begin this work in NetMod. We certainly expect
>     to coordinate the work with the NetConf WG and re-home work as/if
>     needed.
>
>     Finally, we'd also like to thank all those who have contributed to
>     this discussion to date, from problem identification to proposed
>     solutions, and we look forward to your continued efforts to
>     publish a standard solution.
>
>     Lou (and Kent)
>
>
>     On 6/7/2016 10:19 AM, Lou Berger wrote:
>     > 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] <mailto:[e-mail]>
>     > https://www.ietf.org/mailman/listinfo/netmod
>     >
>
>
>     _______________________________________________
>     netmod mailing list
>     [e-mail] <mailto:[e-mail]>
>     https://www.ietf.org/mailman/listinfo/netmod
>
>