Re: [Netconf] yang push drafts

[Andy Bierman <[e-mail]>]

On Thu, May 19, 2016 at 2:15 AM, Juergen Schoenwaelder <
[e-mail]> wrote:

> On Thu, May 19, 2016 at 11:00:59AM +0200, Balazs Lengyel wrote:
> >
> >    1) Implementing yang-push for every data bit e.g. counters will make
> it
> >    difficult for some of our nodes to implement yang-push. I propose to
> have
> >    a yang-extension "not-notifiable"  that indicates that for a specific
> >    data-node datastore change notifications  will not be sent. An
> alternative
> >    could be to define streams that filter out fast changing data-nodes
> like
> >    counters. However how do we know from the model which data nodes are
> >    counters and which are slow changing state data for which
> notifications
> >    are needed: to solve this I think a yang-extension would be good.
> >
>
> I am not sure that pushing this decision to the data model writer is a
> good solution. How does a model writer decide which schema nodes to
> mark as 'not-notifiable'? Sure, there are cases where this may be
> clear but then there are also many cases where it is usage dependent
> whether an object can change too fast or there might be platform
> specific implementation constraints (that should not be documented in
> a data model).
>
> I think there are two alternatives: Make it runtime discoverable on
> which data nodes I can request change notifications or require that I
> can request change notifications on all data nodes but have a
> mechanism in place through which the system can tell me that certain
> data nodes will be excluded. On some systems, I might also have limits
> concerning the granularity (e.g., I get change notifications at max
> every N seconds but not on each individual change).
>
> Anyway, I do not know what the right solution is but to me it sounds
> wrong to push the decision on the data model writer.
>
>


I agree -- the frequency of YANG Push updates is dervied from the usage,
not the definition.

I do not like the use of a subtree filter to select the data do push.
I prefer a list of subtree identifiers.  The server could reject specific
subtree requests
if it decides the update frequency is too high.

A solution that allows the client to know the expected update frequency of
a specific subtree
would be useful.

Resource management is the hardest part of YANG Push.  The current draft
puts an impossible
burden on the server.  A realistic solution would include counters for the
client to inspect,
including drop counters for each subscription receiver address. It would
allow the server
to adjust parameters and report the differences.


/js
>
>
Andy


> --
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
> Fax:   [phone]         <http://www.jacobs-university.de/>
>
> _______________________________________________
> Netconf mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netconf
>