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 <[email protected]
> <mailto:[email protected]>> 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:[email protected]
> <mailto:[email protected]>] On Behalf Of
> > Lou Berger
> > Sent: Wednesday, June 08, 2016 9:06 AM
> > To: [email protected] <mailto:[email protected]>
> > 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 <[email protected] <mailto:[email protected]>>
> > Date: June 7, 2016 10:20:23 AM
> > Subject: [netmod] Opstate solutions discussions: update and
> request for WG
> > input
> > To: netmod WG <[email protected] <mailto:[email protected]>>
> > CC: [email protected] <mailto:[email protected]>
> >
> > 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
> > [email protected] <mailto:[email protected]>
> > https://www.ietf.org/mailman/listinfo/netmod
> >
> >
> >
> > _______________________________________________
> > Rtg-yang-coord mailing list
> > [email protected] <mailto:[email protected]>
> > https://www.ietf.org/mailman/listinfo/rtg-yang-coord
> >
> >
>
>
> _______________________________________________
> Rtg-yang-coord mailing list
> [email protected] <mailto:[email protected]>
> https://www.ietf.org/mailman/listinfo/rtg-yang-coord
>
>
_______________________________________________
i2rs mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/i2rs
