[netconf] Re: YANG Push Lite presentation

[Andy Bierman <[e-mail]>]

On Mon, Nov 11, 2024 at 6:57 AM BL <[e-mail]> wrote:

>
>
> 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.
>
>

RFC 8072 was designed to provide full YANG datastore editing for the
RESTCONF protocol.
It is far more complex to implement than a push-update and also extra work
for the collector.
There is no canonical form of a YANG patch.  There is ultimate flexibility
for the sender and
massive complexity for the receiver,.

Consider an interface entry that has 10 fields changed.
That can be 10 patches with 1 edit each, or 1 patch with 10 edits, or 1
patch with 1 edit,
or anything in between.  There is no requirement to send ONLY the fields
that have changed.
For a collector, it is simpler to get a new representation when needed,
instead of just the leafs that changed.

So maybe we need YANG Push Lite and YANG Patch Lite.
The push-update is almost there to server this purpose.



> The push-update may need some enhancement to say "I really mean a full
> replace this time".
>
>
> Borislav
>>
>
>
> Andy
>
>

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]
>>
>
>