Skip to content

Minutes 2017 02 08

ericvoit edited this page Feb 9, 2017 · 9 revisions
Meeting Materials Attending
WebEx Recording password: zBvDV8fp Susan Hares, Alexander Clemm, Einar Nilsen-Nygaard, Eric Voit, Balazs Lengyel, Mahesh Jethanandani, Alberto Gonzalez

Notifiable-on-change Extension

  • Extension “notifiable-on-change” and Balazs’ text is added into yang-push draft. The extension needs to be activated for targeted trees.
  • Could expose this as a Deviation or YANG Schema annotation per Balazs new draft.
  • There is insufficient activity on the NETMOD alias supporting adoption Balazs' YANG schema annotation draft.
  • We will add text in yang-push Section 3.8.6 assuming deviation. If enough people vote on NETMOD for Balazs’ draft, we can convert to that.

Reviewed changes in YANG models

Periodic Eventing

Last call we talked about the possibility of a “changes only” periodic push. We explored this a little more after recognizing that this would mean that we would need to use the push-change-update which carries the yang-patch.

After the meeting I wrote up some corresponding stuff below. Effectively this proposal would be #4 Periodic Eventing datastore trigger type. Right now our drafts support #1, #2, & #5.

  1. On-Change - Eventing
  • Behavior: Push every subscribed object change as it happens
  • Use with: infrequent, non-bursty changes going into interrupt based applications (e.g., monitoring config)
  1. On-Change - Subscription Dampened
  • Behavior: Push sum of changes across the whole subscription no more quickly than once every ‘X’ seconds
  • Use with: infrequent, bursty changes going into interrupt based applications (e.g., Telemetry deltas)
  1. On-Change - Object Dampened
  • Behavior: Push changes for any object in a subscription no more quickly than once every ‘X’ seconds
  • Use with: infrequent, bursty changes digested individually by interrupt based applications (e.g., operational state fluctuations)
  1. Periodic Eventing
  • Behavior: Push sum of changes across the whole subscription every ‘X’ seconds
  • Use with: infrequent, bursty changes and applications running on a known, anchored cadence
  1. Periodic Complete
  • Behavior: Push all subscribed objects every ‘X’ seconds
  • Use with: majority of elements change frequently, with applications running on a known, anchored cadence (e.g., Telemetry)

After the meeting thought more about #4, and how to morph the YANG model to accomplish this. The changes are quite doable. But after more thinking I there is little reason to add the complexity. Basically the only behavior which #2 doesn’t support is the ability to push deltas based on a specific anchor time. Meaningful use of this anchor time would require either:

  • cadence based applications which look at synchronized extracts of non-counter-based bursty operational state across subscriptions/devices.
  • a compression method across subscriptions which allows one object in both subscriptions to be sent only once for both subscriptions should the anchor times align.

These benefits doesn’t seem worth the complexity, and therefore #4 don't seem worth including in our scope at this point.