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 <lber...@labn.net
> <mailto:lber...@labn.net>> 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
> > netmod@ietf.org <mailto:netmod@ietf.org>
> > https://www.ietf.org/mailman/listinfo/netmod
> >
>
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org <mailto:netmod@ietf.org>
> https://www.ietf.org/mailman/listinfo/netmod
>
>
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
