Subject: Re: [Netconf] yang push drafts

From: Balazs Lengyel <[email-masked]>
Date: Thu, 19 May 2016 11:00:59 +0200

Hello Eric,

As indicated on yesterdays interim meeting, we have some issues
with the yang-push draft

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.

2) If I have an on-change subscription and I loose some
notifications it is much cheaper to somehow playback those
notifications than to get the full datastore (or subtree). We would
need a replay capability to get the lost notifications. This also
implies the need for a way to detect st notifications. I concur with
Juergen that a sequence number for the notifications would be good.

3) For an on-change subscription in some cases  (e.g. reload,
upgrade, etc.) there are so many changes that instead of sending
them all, it would be better to :

- the node suspends change notifications

- the node sends a special notification change-notifications-lost or
resynchronization-proposed. This would allow the client to
re-synchronize, read the datastore with a get operation.

As an example, there is no sense sending individual changes when 70%
of the datastore changed.

Opinions?

regards Balazs

--
Balazs Lengyel Ericsson Hungary Ltd.
Senior Specialist
Mobile: +36-70-330-7909 email: [email-masked]

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 19 May 2016 11:15:28 +0200

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.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: "Alberto Gonzalez Prieto (albertgo)" <[email-masked]>
Date: Thu, 19 May 2016 09:31:39 +0000

Hi Balazs,

From: Netconf <[email-masked]<mailto:[email-masked]>> on behalf of Balazs Lengyel <[email-masked]<mailto:[email-masked]>>
Date: Thursday, May 19, 2016 at 2:00 AM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Netconf] yang push drafts

Hello Eric,

As indicated on yesterdays interim meeting, we have some issues with the yang-push draft

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.

[AG] Does the requirement apply to on-change subscriptions only?  Or also to periodic?
An option is for the server to reject subscriptions that cannot be served (I.e., on-change updates of fast-changing state).
Using the negotiation mechanism, it can guide the client stating that it cannot serve on-change subscriptions for the requested data nodes, but it can serve periodic updates
[/AG]

2) If I have an on-change subscription and I loose some notifications it is much cheaper to somehow playback those notifications than to get the full datastore (or subtree). We would need a replay capability to get the lost notifications. This also implies the need for a way to detect st notifications. I concur with Juergen that a sequence number for the notifications would be good.

3) For an on-change subscription in some cases  (e.g. reload, upgrade, etc.) there are so many changes that instead of sending them all, it would be better to :
- the node suspends change notifications
[AG] subscription suspensions are decided unilaterally by the server. The suspension is notified to the subscribers/receivers, including the reason for the suspension.
[/AG]

- the node sends a special notification change-notifications-lost or resynchronization-proposed. This would allow the client to re-synchronize, read the datastore with a get operation.
As an example, there is no sense sending individual changes when 70% of the datastore changed.

[AG] would a synch-on-resume flag address this?
The semantics being similar to those of the synch-on-start on the draft, and also being part of the subscription request.
(Both flags may be combined into just one)
[/AG]

Opinions?

regards Balazs

--
Balazs Lengyel                       Ericsson Hungary Ltd.
Senior Specialist
Mobile: +36-70-330-7909              email: [email-masked]<mailto:[email-masked]>

---

From: Andy Bierman <[email-masked]>
Date: Thu, 19 May 2016 07:47:31 -0700

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

> it

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

> _______________________________________________
> Netconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netconf
>