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

["Acee Lindem (acee)" <[e-mail]>]

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



>
>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
>