[netconf] Re: YANG Push Lite presentation

[Andy Bierman <[e-mail]>]

On Mon, Nov 11, 2024 at 9:55 AM Rob Wilton (rwilton) <[e-mail]>
wrote:

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


Yes the server or linecard is required to collect data and only send it all
when the dampening period for the subscription has passed.
It is per subscription, not per-linecard or per-receiver.  This seems
nearly impossible to implement across multiple linecards,
each contributing to multiple subscriptions.

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


OK


OLD:

       leaf dampening-period {
               type centiseconds;
               default "0";

NEW:

      leaf dampening-period {
               if-feature dampening;
               type centiseconds;
               default "0";


On the subject of getting rid of complexity:

RFC 8639, sec 2.8

   To understand the flow of event records in a subscription, there are
   two counters available for each receiver.  The first counter is
   "sent-event-records", which shows the number of events identified for
   sending to a receiver.  The second counter is "excluded-event-
   records", which shows the number of event records not sent to a
   receiver.  "excluded-event-records" shows the combined results of
   both access control and per-subscription filtering.  For configured
   subscriptions, counters are reset whenever the subscription's state
   is evaluated as "valid" (see (1) in Figure 8).


These counters are too complicated to implement if distributed
linecards are the publishers.
The excluded-event-records is too complex to maintain in any implementation.

IMO these counters should be deprecated or made optional with if-feature.
A byte and event counter for each receiver and each publisher would be
easier to maintain
and maybe more useful to the operator.


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

+1

It is clear that different use-cases for YANG Push exist and changes are
need to support them.



> Regards,
>
> Rob
>
>
>


Andy


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