Subject: [Netconf] Minutes 8-Feb: NETCONF/RESTCONF/HTTP2 Subscription & Event drafts

From: "Eric Voit (evoit)" <[email-masked]>
Date: Thu, 9 Feb 2017 22:22:50 +0000

Minutes posted at:
https://github.com/netconf-wg/yang-push/wiki/Minutes-2017-02-08

·        As always, our DezignTM Team is a gathering of individuals providing informal input to NETCONF. We ask NETCONF WG to comment on our discussion results as a preparation for the WG consensus. Please approach Eric Voit if you want to be included directly in these meetings.

Meeting Materials

Attending

WebEx Recording<https://cisco.webex.com/ciscosales/lsr.php?RCID=f0c9c57f7e3e4df1ac7ab6b9c12449f8>
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

  *   Pending drafts are here:
     *   https://github.com/netconf-wg/yang-push/blob/master/draft-ietf-netconf-yang-push-05%402017-02-08.txt
     *   https://github.com/netconf-wg/rfc5277bis/blob/master/draft-ietf-netconf-subscribed-notifications-00-v08Feb2017.txt
     *   both “draft-previously-known-as-5277bis” and “yang-push” in a state ready to be pushed as an updates to IETF
  *   We reviewed lots of updates during the call. You can see the list of the document changes in the version appendices. Key updates worth extra highlighting include:
     *   Name changing from 5277bis to subscribed-notifications.
        *   Mehmet: you can change the name without waiting on charter as the charter doesn’t dictate document names
     *   Error code: add new identity for synch-on-start to large
        *   With this we can close wiki issue #5 on error types
  *   Balazs is willing to give the examples a scrub

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)
  2.  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)
  3.  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)
  4.  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
  5.  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.