[netconf] Re: YANG Push Lite presentation

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

Hi Andy:

Re: Issue with Dampening:

The way dampening is defined in RFC 8641 is per subscription.  So, if you are subscribed for interface link state changes for all interfaces in a single subscription (reasonably plausible), that will mean that if one interface goes down within the dampening period, then it would also dampen link state change notifications for all interfaces, which is probably not that useful or helpful.  Alternatively, you could have a separate subscription per interface, but that could then mean 10K+ subscriptions for interface state changes, i.e., also not that helpful.

Really, for dampening to be useful for on-change, it needs to be done per list entry or per leaf, and that requires the server to maintain much more operational state so that it can determine whether anything has actually changed.  When we discussed dampening with the operators then no-one wanted/needed it.  Instead, if a particular leaf needs to be dampened then the suggestion was to define that within the data model.  E.g., this is exactly what we do on our systems for interface link state.  We have various configuration options (interface dampening and carrier-delay) that allow dampening to be applied on a per-interface basis that means that for a subscription we would notify interface state changes more slowly (perhaps fast down, slow up) and hence no telemetry subscription level dampening is needed – it is handled elsewhere or a needed basis.

Probably we want to have some text to allow a server to dampen on-change notifications if appropriate, as long as it doesn’t completely lose the fact that a change has occurred and must be reported after the dampening period.  I.e., a much softer guarantee of on-change events than the existing RFC 8641 text that requires that every single change is always notified (including if a value has been reverted).

In short, my goal is to put the minimum requirements on the server to satisfy the requirements coming from the operators for the collectors.  Extra complexity can always be augmented in to the model by separate drafts if really needed, but it helps keep the base model simpler and easier to implement.

Regards,
Rob



From: Andy Bierman <[e-mail]>
Date: Friday, 8 November 2024 at 16:08
To: Netconf <[e-mail]>
Subject: [netconf] YANG Push Lite presentation
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