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

[Andy Bierman <[e-mail]>]

On Wed, Jul 13, 2016 at 2:43 AM, Robert Wilton <[e-mail]> wrote:

> Please see RW: inline
>
> On 12/07/2016 20:15, Andy Bierman wrote:
>
>
>
> On Tue, Jul 12, 2016 at 12:07 PM, Juergen Schoenwaelder <
> <[e-mail]>[e-mail]
> > wrote:
>
>> On Tue, Jul 12, 2016 at 11:36:03AM -0700, Andy Bierman wrote:
>> > Yes there is value in modeling conventions in general.
>> > I am trying to understand the value of this specific convention.
>> >
>> > If I have an RPC that asks for applied state, then it doesn't really
>> matter
>> > how the config and state is organized.  There is only overlap in the
>> objects
>> > if the data model is designed that way.
>> >
>> > Whether or not an edit is applied yet is a property of the
>> implementation,
>> > not the data model.
>>
>> The current /foo and /foo-state approach requires some amount of
>> duplication. If the trees contain some nested lists of lists, you have
>> to at least replicate all the key leafs in the schema definition. For
>> a small model, this is not a bit deal; for more complex models, this
>> becomes complex and there are possible sources of errors. If it is
>> possible to simply data models, this may be a long-term win.
>>
>>
>
> It only requires duplication if you insist on modeling opstate objects.
> IMO an RPC + notification approach is far superior.
>
> RW:
>
> Are you thinking of a single global notification of convergence?
>


No

I think the client would request a notification for its edit.
There would be a long-form and short-form notification.

The interaction model is simple:
   A) at the time of the request the client opt-in for being notified
   B) the server will send the short form (all-ok) ASAP or even return the
short-form all-ok
        in the response and skip the notifications if possible
    C) if the timeout occurs, then the server sends the long-form
notification, which lists
         all the intended config operations not yet applied.  (This is
easier to do for YANG Patch
        where the edits are identified, than with <edit-config> that has an
unordered blob of XML).


Parameters would be added to the edit request:

    - want-notif:  (boolean: default false)
    - notif-timeout: how long the server should wait before sending the
long-form notification
    - trace-id:  string provided by the client similar to persist-id that
will identify this edit
       in the notifications


This approach does not deal with multi-client conflicts.
If client A does "create /foo" then the server ACKs that edit even if
client B
has started a subsequent "delete /foo" edit before the first edit was ACKed.

A separate RPC to retrieve the long-form notification for all pending edits
would
also be needed to allow for a notification to be lost or a client to query
the entire
list of unapplied edits.


Andy




> Although such a scheme may be sufficient if the configuration is changing
> infrequently, it is not sufficient for a system in which configuration is
> changing frequently (e.g. say to provision very short lived tunnels across
> a data center network).
>
> If the client is interested when a particular config change has converged
> then a global converged flag:
>  (i) may be delayed a long time (if at all) after the config change has
> completed (because other subsequent config operations are in progress)
>  (ii) may be hard to relate back to the original config change
>
> Hence, I think that there are only 2 technical solutions to this problem:
> (a) reporting/notifying the state of the applied configuration nodes (as
> per the requirements stated in draft-ietf-netmod-opstate-reqs, and covered
> by the all the various solution drafts)
> (b) report the success/failure of the particular config operation.
>
> My opinion, is that as network configuration becomes more dynamic, and
> programmatically controlled then (a) is the easier solution and more robust
> to failure over (b).  But both approaches can be supported by devices.
>
>
> In this approach I only need to identify the intended config object
> and retrieve (or be notified) of the applied-state transition.
>
> RW:
>
> This is only part of the solution, since metadata can only be used when
> nodes exist in the YANG data tree.  So, this method alone cannot indicate
> configuration that is applied by the device and is in the process of being
> deleted.
>
> That is primarily why draft-wilton-netconf-opstate-metadata-00 offers
> metadata both on the "persistent" datastore and "operational state
> datastore".
>
>
>
>
>
>
>> The reason why we have the /foo and /foo-state convention is, I
>> believe, the design of the NETCONF <get/> operation, which assumes
>> state and config can be represented together in a single tree. And we
>> have carried this further into YANG (e.g., the way contexts are
>> constructed for xpath expressions). In hindsight, I am not sure the
>> consequences of the <get/> design were that well thought through - but
>> I am not complaining, at that time we did not have YANG nor did we
>> have experience with bigger data models written in YANG. Is it worth
>> fixing it? This is a tough question and I understand that people have
>> different opinions and also different views on where we are on the
>> lifecycle of this technology. The challenge, as always, is to evolve a
>> technology along with its usage and upcoming new requirements. If the
>> evolution is too fast, you risk fragmentation since people will then
>> run many different versions. If evolution is too slow or stops
>> entirely, you pave the way for complete replacements of the
>> technology.
>>
>> I think it is worth to step back for a moment and to think about where
>> we like to be in 5 or 10 years from now when we discuss architectural
>> questions.
>>
>
>
> We have read-only foo-state because we have only been standardizing
> monitoring data for the last 30 years.  I completely agree that if the
> state depends
> on the config in order for an instance to exist, then co-locate the config
> and
> state and share the node naming.
>
>
> But modeling admin-state and oper-state with the same object is not a
> requirement.
>
> RW:
>
> I agree, but when the oper-state exactly of a node reflects the applied
> admin-state then I see no benefit in having a separate duplicate "config
> false" node.
>
> Rob
>
>
> Being able to determine if the intended config is applied yet is a
> requirement.
> This can be done with protocol operations so it is 100% data model neutral.
>
>
>
>
>>
>> /js
>>
>
> Andy
>
>
>>
>> --
>> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
>> Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
>> Fax:   [phone]         < <http://www.jacobs-university.de/>
>> http://www.jacobs-university.de/>
>>
>
>
>
> _______________________________________________
> netmod mailing [e-mail]://www.ietf.org/mailman/listinfo/netmod
>
>
>