1. Evolution of the Subscription & Event Notification Drafts IETF #98 Chicago Eric Voit 28-Mar-2017 DRAFT
Authors on at least 1 drafts
Andy Bierman
Alexander Clemm
Balazs Lengyel
Einar Nilsen-Nygaard
Alberto Gonzalez Prieto
Ambika Prasad Tripathy
Eric Voit
+ Contributors
Sharon Chisholm
Yan Gang
Peipei Guo
Susan Hares
Tim Jenkins
Michael Scharf
Hector Trevino
Kent Watsen
Guangying Zheng (Walker)
The subteam met ½ dozen times since IETF 97
And assembled and reviewed proposals on quite a few issues. Minutes and mechanisms were sent to NETCONF WG mailer. We will talk about several of these during todays presentation.
We are now at a point where we are very close to going to WG last call on several drafts.
The now successfully
retired
Dezign Team TM

2. Data Replication Frequency vs. Latency
This is the new stuff enabled
One of the slides we discussed as a subteam is this one. It shows why push matters.
Until recently many people have seen on-change as equivalent to eventing. It is not. The goal of on-change is to maintain an extract of datastore to be maintained. Therefore datastore patch operations -- adding changing deleting nodes are the mechanism used. 2

3. Functional Partitioning Summary
Subscribed Notifications
YANG Datastore Push
Subscription
Types
Dynamic and Configured
per Session
many
Negotiation
Yes
RPCs
establish, modify, delete, kill
State Notifications
started, suspended, resumed, terminated, modified
Data Plane Notifications
basic
RFC Subscription-ID
complete and changes
Headers
Update Bundling
Transport
NETCONF
RESTConf, HTTP, HTTP2
To accomplish this, we have been working the four WG drafts, and have a new fifth one which hits a new YANG question which I will highlight at the end of this session.
Before getting there, I would like to highlight tweaks of of key functionality.
we renamed control plane notifications into state change notifications. These notifications are required to ensure that datastore patch operations are processed correctly.
we removed RFC5277 coverage for reasons detailed on the ML.
We have detailed more on the data plane notifications via additions to YANG 1.1 notifications.
draft-ietf-netconf-yang-push
draft-ietf-netconf-subscribed-notifications
draft-voit-netmod-yang-notifications2
draft-ietf-netconf-event-netconf
draft-ietf-netconf-event-restconf
Legend 3

4. Functionality per Draft
Subscribed Notifications
Dynamic & Configured subscriptions
Multiple subscriptions / transport
Multiple configured receivers
Establish, modify, delete, kill RPC
State change notifications
Suspend/resume
Filtering full notifications
Stream discovery
Replay (and start time negotiation)
Prioritization
Monitoring / reporting
QoS
Error responses
YANG Datastore Push
Datastore on-change and periodic triggers
Filtering objects within a notification
Authorization model per object
Sending of full YANG trees or yang-patch
Tagging of partial updates
Tagging of on-change object support
Negotiation of filters and period lengths
More error responses
YANG Notifications2
Encapsulation Headers objects: Signature, de-duplication, severity, originator
Bundled records and record types
NETCONF Transport for Subscribed Notifications
Transport mapping
RESTCONF & HTTP2 Transport for Subscribed Notifications
Transport mappings (including HTTP2 QoS)
Heartbeats and clean-up
draft-ietf-netconf-yang-push
draft-ietf-netconf-subscribed-notifications
draft-voit-netmod-yang-notifications2
draft-ietf-netconf-event-netconf
draft-ietf-netconf-event-restconf
Legend 4

5. Drafts in Layered Framework
Application
Subscriber
Receiver
Publisher
Subscription
Mgmt
Update
Packaging
and
Flow Control
Transport
Session
TLS
SSH
HTTP2
HTTP1.1
gRPC
Restconf
Netconf
Encoding
Thrift
CBOR
GPB
JSON
XML
Dynamic
Configured
Subscription Mtc
YANG
Admission Control
OAM
Negotiation
Event Notification
Generation
Stream Discovery
Bundling
Filtering
Access Control
On-Change
Periodic
Event
Generation
Applied Config
Operational State
NETCONF
Stream
custom
Running
Config
Startup
Config
Candidate
Config
Intended
Config
Control
Plane
Control
Plane
draft-ietf-netconf-yang-push
draft-ietf-netconf-subscribed-notifications
draft-voit-netmod-yang-notifications2
draft-ietf-netconf-event-netconf
draft-ietf-netconf-event-restconf
Legend 5

6. Updates since IETF #97 yang push -05 revision
Ability to get operational data from filters
Extension notifiable-on-change added
New appendix on potential futures
New error and hint mechanisms included in text and in the YANG model
Updated examples based on the error definitions
Text updates

7. Final steps before WG Last Call
yang push
Final steps before WG Last Call
Subscription ID as an identifier only relevant to a single receiver
Deferral of a standard header and bundle support (i.e., use the current data plane notifications.)
The same subscription id can be used between two receivers of the same configured subscription. But due to NACM filtering rules, you can’t assume each is getting identical updates unless both receivers have identical access control permissions.
One other capability which I should have put on this list is a need to allow receive a patch with a delete on a non-existent node, or a create on an existing node. Because of the need to support dampening, this is the way you signal changes have occurred even though you have returned you to your original state. I will make sure this is reiterated on the mailing list. 7

8. subscribed-notifications
Updates since IETF #97
subscribed-notifications
Move away from 5277bis
Kill subscription RPC added
Error conditions added
YANG model simplifications
Renaming of Subscription State Notifications and identifiers

9. Final steps before WG Last Call (Same as for YANG-Push)
subscribed-notifications
Final steps before WG Last Call (Same as for YANG-Push)
Subscription ID as an identifier only relevant to a single receiver
Deferral of a standard header and bundle support (i.e., use the current data plane notifications.) 9

10. Updates since IETF #97 Restconf / HTTP2 -02 revision
Removed sections redundant with other drafts
3rd party subscriptions out of scope
SSE only used with RESTCONF and HTTP1.1 Dynamic Subscriptions.

11. Final steps before WG Last Call
Restconf / HTTP2
Final steps before WG Last Call
HTTP2 transport message compatibility with GRPC
One set of meetings. Need another set of eyes
As expressed here over the last three IETFs our goal remains having the messages transported over HTTP2 be as close as possible, if not identical, to what might be transported over GRPC. To help with this goal, we have done things like convert messages to POST rather than GET.
After the request made at the last meeting, there was one meeting with Eric Anderson on the GRPC question. We do know that it is possible. But we have not been able to progress farther. At this point without further assistance, we will just be going with HTTP2 support. If there is anyone out there who is willing to help with validating the mapping here, please contact me. 11

12. No Updates since IETF #97 Notif-netconf -02 revision coming shortly
(was awaiting 5277bis Charter solidification)

13. draft-voit-netmod-yang-notifications2 Proposes Solutions to the Following:
1. What are the set of transport agnostic header objects which might be usefully placed within YANG notifications? 2. How might a set of YANG notifications be bundled into a single transport message? 3. How do you query the originator of a notification to troubleshoot the bundling process?
In my day job I work some cloud security applications. People there want to synch datastores between devices without depending too much on any particular transport.
Question: independent of any transport protocols, how do applications define information elements objects which might go into a queue for later transport?
Question: when volumes of notifications go up, how do you bundle many of these into a single transportable message. This is a problem which the recent GNMI proposal also identifies.

14. #1 Transport Agnostic Header Objects
notifications2
+---n notification-message
+--ro notification-message-header
| +--ro record-time
| +--ro record-type?
| +--ro record-id?
| +--ro record-severity?
| +--ro observation-domain-id?
| +--ro subscription-id?
| +--ro notification-time?
| +--ro notification-id?
| +--ro previous-notification-id?
| +--ro signature?
| +--ro message-generator-id?
+--ro receiver-record-contents?

15. #2 bundling multiple notifications into a single transportable message
+---n bundled-notification-message +--ro notification-message-header | +--ro notification-time | +--ro notification-id? | +--ro previous-notification-id? | +--ro signature? | +--ro message-generator-id? | +--ro record-count? +--ro notification-records* +--ro notification-record-header | +--ro record-time | +--ro record-type? | +--ro record-id? | +--ro record-severity? | +--ro observation-domain-id? | +--ro subscription-id? +--ro receiver-record-contents?
How many people find this an interesting problem. Is there interest in reviewing additional drafts in this space, with a goal of an eventual adoption vote?

16. Thank you!