[netconf] Re: YANG Push Lite presentation

["Rob Wilton (rwilton)" <[e-mail]>]

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]<mailto:[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]<mailto:[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]<mailto:[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]<mailto:[e-mail]>
To unsubscribe send an email to [e-mail]<mailto:[e-mail]>



_______________________________________________

netconf mailing list -- [e-mail]<mailto:[e-mail]>

To unsubscribe send an email to [e-mail]<mailto:[e-mail]>

_______________________________________________
netconf mailing list -- [e-mail]<mailto:[e-mail]>
To unsubscribe send an email to [e-mail]<mailto:[e-mail]>