[netconf] Re: YANG Push Lite presentation

[BL <[e-mail]>]

Basically the proposal is to change notification used in on-change 
subscription to be a "modified-push-update"
(indication of operation: merge or delete, can include only a subset of 
the "full" update,  includes objects that are not changed, ...)?

Client won't be able to tell whether the object has changed or not if 
the value for that object in notification
is the same as the value of the object already known by the client.
I.e. client should understand that notification contains the current 
state of the (subset of) subscribed values.

I think that this is reasonable.

Borislav



On 11/11/2024 1:08 PM, Rob Wilton (rwilton) wrote:
>
> Hi Borislav,
>
> Please see inline …
>
> *From: *BL <[e-mail]>
> *Date: *Monday, 11 November 2024 at 14:58
> *To: *Andy Bierman <[e-mail]>
> *Cc: *[e-mail] <[e-mail]>
> *Subject: *[netconf] Re: YANG Push Lite presentation
>
>
>
> On 11/8/2024 7:21 PM, Andy Bierman wrote:
>
>     On Fri, Nov 8, 2024 at 4:01 PM BL <[e-mail]> wrote:
>
>         Hi Andy,
>
>         dampening-period is for both the subscriber/client and the
>         publisher/server.
>         Server should implement
>         ietf-system-capabilities/ietf-notification-capabilities (or
>         similar model)
>         so the client can examine capabilities of the server before
>         subscribing.
>
>     I am aware of that YANG module.
>
>     My comment was about the slide that said that dampening  should be
>     removed from YANG Push.
>
>     This is the only standard way for an operator can limit the send
>     rate of each publisher.
>
>     Seems kind of important for UDP.
>
>         You propose to remove "push-change-update" and use
>         "push-update" instead in "on-change" subscription.
>         Which sounds reasonable since "push-change-update" is
>         complicated to implement.
>         Could you clarify:
>         "Also agree that a push update is not a full replace, but
>         rather just gather what is being reported."
>
>     The example in the meeting was a subscription for an entire
>     datastore, but consider a filter for /interfaces.
>
>     If an update only contains  1 interface
>     (/interfaces/interface[name='foo']) that does not mean all the
>     other interfaces
>
>     have been deleted.  This is not as precise as YANG Patch but much
>     easier to implement.
>
>
> So this would be a "push-change-update" but in a different form, i.e. 
> modified "push-update" ?
> I don't see how this makes implementation easier.
>
> There are probably 3 main benefits:
>
>  1. Just choosing a simpler/less verbose format than YANG Patch.
>  2. Simplifying the change type to just “exists with value” (i.e.,
>     create/update) vs “doesn’t exist” (i.e., delete) (TBD – figure out
>     if we need special handling for changes to list keys or reordering
>     user-ordered lists).
>  3. Allowing a receiver to get both period and on-change notifications
>     in the same subscription and share a lot of the code for
>     processing message.
>
> So, the desire to change the format has come from both implementation 
> experience on the server side, and also from the consumer side, i.e., 
> the operators who are consuming the telemetry data.  The goal of this 
> work is to simplify the task to efficiently replicating state from a 
> server to a client, rather than trying to give an indication as to 
> how/why the state has changed which in many cases would encourage a 
> fragile solution (e.g., it is unlikely that behaviour can be 
> guaranteed if the connection is lost, or a daemon on the server is 
> restarted).  Instead, we revert to notifying simpler state that the 
> server should be able to provide accurately.
>
> Regards,
> Rob
>
>     The push-update may need some enhancement to say "I really mean a
>     full replace this time".
>
>         Borislav
>
>     Andy
>
>
>         On 11/8/2024 11:37 AM, Andy Bierman wrote:
>
>             On Fri, Nov 8, 2024 at 8:17 AM Reshad Rahman
>             <[e-mail]> wrote:
>
>                 Hi Andy,
>
>                 > I do not understand the issue with dampening.
>
>                 Within the implementation, it means how often you
>                 check for changes.
>
>                 It is effectively the same as the 'period' for a
>                 periodic subscription.
>
>                 How does an on-change subscription work without this
>                 parameter?
>
>                 In the context of continuously changing data such as
>                 counters I understand the statement above. But for
>                 state changes, dampening-period isn't needed (although
>                 I realize this is implementation specific).
>
>             So it should be optional I guess.
>
>             This parameter is for the subscriber, not the publisher.
>
>             It means "do not send me an update more frequently than N
>             centiseconds".
>
>                 Regards,
>
>                 Reshad.
>
>             Andy
>
>                 On Friday, November 8, 2024 at 11:08:24 AM EST, Andy
>                 Bierman <[e-mail]> wrote:
>
>                 Hi,
>
>                 I hope this work gets high priority.
>
>                 There are many I-Ds already so please do not start
>                 over or greatly expand the scope.
>
>                 I have been saying that YANG Push is too complicated
>                 since I was on the DT
>
>                 that created RFC 8639,40,41.
>
>                 We have a fairly complete implementation of dynamic
>                 subscriptions.
>
>                 Glad to see there is now consensus to get rid of the
>                 YANG Patch update.
>
>                 We decided the same thing a long time ago:
>
>                 https://docs.yumaworks.com/en/latest/cli/netconfd-pro.html#push-simop-patch-update
>
>                 Also agree that a push update is not a full replace,
>                 but rather just
>
>                 gather what is being reported.  That is also how our
>                 server works.
>
>                 I do not understand the issue with dampening.
>
>                 Within the implementation, it means how often you
>                 check for changes.
>
>                 It is effectively the same as the 'period' for a
>                 periodic subscription.
>
>                 How does an on-change subscription work without this
>                 parameter?
>
>                 Andy
>
>                 _______________________________________________
>                 netconf mailing list -- [e-mail]
>                 To unsubscribe send an email to [e-mail]
>
>
>
>             _______________________________________________
>
>             netconf mailing list [e-mail]
>
>             To unsubscribe send an email [e-mail]
>
>         _______________________________________________
>         netconf mailing list -- [e-mail]
>         To unsubscribe send an email to [e-mail]
>