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

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

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-7950 + 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

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

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

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

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

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

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

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.

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

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

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.

#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?

#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?

Thank you!