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

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

Hi Lou, 
I’m not advocating this #2. If you are going to rely on the revised data
stores to obtain the information, you should go all the way to #3. For
example, based on the control-plane-protocols in routing-cfg, we have
separate top level containers for config state.

 +--rw routing
      +--rw router-id?
      +--rw control-plane-protocols
      |  +--rw control-plane-protocol* [type name]


And:
+— ro routing-state
      +--ro router-id?
      +--ro interfaces
      |  +--ro interface*
      +--ro control-plane-protocols
      |  +--ro control-plane-protocol* [type name]
      |     +--ro type
      |     +--ro name


The control plane protocols augment these two lists separately. With #2,
we leave the bifurcated structure and simply remove the data nodes that
are not needed from the protocol state.

Thanks,
Acee 

On 7/12/16, 11:23 AM, "Lou Berger" <[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-00
>>>> [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
>
>