Re: [netmod] OpsState Direction Impact on Recommended IETF YANG Model Structure

[thomas nadeau <[e-mail]>]

> On Jul 15, 2016, at 5:48 PM, Acee Lindem (acee) <[e-mail]> wrote:
> 
> 
> 
> On 7/15/16, 10:23 AM, "Robert Wilton -X (rwilton - ENSOFT LIMITED at
> Cisco)" <[e-mail]> wrote:
> 
>> 
>> 
>>> On 15/07/2016 15:16, Acee Lindem (acee) wrote:
>>> 
>>>> On 7/14/16, 4:00 PM, "Kent Watsen" <[e-mail]> wrote:
>>>> 
>>>> [This thread took on a life of its own, so I’m replying to this email
>>>> from two days ago]
>>>> I had assumed the plan/recommendation would be:
>>>>  - for works-in-progress, to evaluate if their models can be improved.
>>>>  - for existing RFCs, do nothing (though we may want to consider
>>>> RFC7223).
>>>> 
>>>> By “if their models can be improved” in the above, I’m implying that
>>>> having a top-level -state branch may still be the best solution for
>>>> some
>>>> models.  It’s up to each model designer to decide the best approach for
>>>> their models.
>>>> 
>>>> Makes sense?
>>> I think the statement “if their models can be improved” leaves too much
>>> subjectivity in the guideline. Either we are going to avail the revised
>>> data store model to avoid duplication of YANG schema nodes or we are
>>> going
>>> to leverage the new data stores solely to meet the intended/applied
>>> config
>>> requirement. If it is the latter and a good portion of the network
>>> devices
>>> will not support, then I would agree.
>> Devices can still leverage the new operational state datastore (and
>> hence allow foo and foo-state to be merged) without having to supporting
>> an intended/applied configuration split (i.e. they just treat applied =
>> intended).
> 
> Right - but then the applied configuration wouldn’t be available for the
> cases where it does differ from intended configuration.
> 
>> 
>> I'm keen to get the models simpler were possible because I think that
>> will help with their longevity and ease of use.
> 
> For the record, I agree. However, reaching consensus will be difficult.
> 
> Thanks,
> Acee

Indeed. There are enough people wanting to do this both ways that it will be difficult at best.

tom





> 
> 
> 
>> 
>> Thanks,
>> Rob
>> 
>> 
>>> 
>>> 
>>> 
>>> 
>>>> Kent  // as a contributor
>>>> 
>>>> 
>>>> On 7/12/16, 11:23 AM, "netmod on behalf of Lou Berger"
>>>> <[e-mail] on behalf of [e-mail]> wrote:
>>>> 
>>>> Acee,
>>>> 
>>>>    I personally was assuming we'd follow 3, but I'd like to understand
>>>> the implication of 2 as I'm not sure I really understand what you're
>>>> thinking here.  Can you elaborate what you're thinking here?
>>>> 
>>>> Thanks,
>>>> 
>>>> Lou
>>>> 
>>>>> On 7/11/2016 12:36 PM, Acee Lindem (acee) wrote:
>>>>> While there are details to be worked out between the two data stores
>>>>> models (as indicated below), we now have implicit modeling of applied
>>>>> configuration. Existing models (both standard and draft) do not take
>>>>> this
>>>>> into consideration and, consequently, much of the state that is
>>>>> modeled
>>>>> explicitly represents the application configuration. For the RFC
>>>>> models,
>>>>> it probably doesn’t make much sense to redo them (unless they are
>>>>> being
>>>>> reworked for other reasons). This still leaves the existing WG draft
>>>>> models for which we have basically 3 options:
>>>>> 
>>>>>   1. Do nothing - allow them proceed as they are with multiple ways
>>>>> of
>>>>> representing the applied configuration. This would provide visibility
>>>>> to
>>>>> the data independent of whether or not the device supported the
>>>>> revised
>>>>> data-stores supporting implicit retrieval of the applied
>>>>> configuration.
>>>>>   2. Prune out the redundant data nodes except those required as list
>>>>> keys, etc, since they can be obtained from the applied state data
>>>>> store.
>>>>>   3. #2 plus collapse the config (read-write) and  system-state
>>>>> (read-only) into common containers. No more branching of
>>>>> <model-name>-config and <model-name>-state at the top level of the
>>>>> model.
>>>>> 
>>>>> At I high-level, I feel these are the options. I’m not married to any
>>>>> one
>>>>> of these and the worse thing we could do is hold up progression of the
>>>>> existing YANG model drafts for another couple years while we debate
>>>>> the
>>>>> best course. Having said that, #3 is compelling since it will yield
>>>>> the
>>>>> most concise models and colocates the schema data nodes for any
>>>>> managed
>>>>> object.
>>>>> 
>>>>> Thanks,
>>>>> Acee
>>>>> 
>>>>> On 7/1/16, 12:36 PM, "netmod on behalf of Lou Berger"
>>>>> <[e-mail] on behalf of [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-0
>>>>>>> 0
>>>>>>> [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
>>>>> _______________________________________________
>>>>> netmod mailing list
>>>>> [e-mail]
>>>>> https://www.ietf.org/mailman/listinfo/netmod
>>>> 
>>>> _______________________________________________
>>>> netmod mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/netmod
>>> _______________________________________________
>>> netmod mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/netmod
> 
> _______________________________________________
> netmod mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netmod