[netconf] Re: YANG Push Lite presentation

[Andy Bierman <[e-mail]>]

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.

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 to [e-mail]
>
>
> _______________________________________________
> netconf mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>