Minutes 2016 10 19

Meeting Materials	Attending
WebEx Recording password: ZwtX2CHj	Andy Bierman, Alexander Clemm, Ambika Tripathy, Einar Nilsen-Nygaard, Eric Voit, Tim Jenkins, Balazs Lengyel, Kent Watsen, Walker

Debate today was on whether to use streams, and which ones should be defined in the draft(s). The basic question comes from where should we place the complexity of the overall filtering. Specifically: is it better to have a single complex filter on a network element without a stream, or is it better to have a standardized pre-filter which reduces the domain of objects against which a user defined stream is applied.

We had rough consensus on the following:

• Existing Netconf stream construct needs to stay
• There is use in having optional custom vendor YANG stream(s) acting as a pre-filter that can be assigned by a vendor
• If no stream is defined, this means the universe of all YANG objects on a device is in scope
• Note: If/when OpState is adopted, then a default of no-filter might prove problematic as all YANG objects could mean all YANG objects across all datastores.

We had majority, but no final consensus on the following:

• We should have a standard list of streams that vendors can choose to support on a device.
• The definition of what the list should be can be updated over time. (i.e., Perhaps this list shouldn’t be in the base technology spec.)
• Example of something which would be a useful standardized stream would be a Hardware Events stream. Predefining all of these via filter is not viable as different vendors might expose their models within a box, and will change as new models are added.
• Vendor streams for notifications of 5277bis events might also be useful, and should be assignable

We had other discussions on:

• Named stream definitions will need to consider and map to the OpState discussions. We don’t want to create unnecessary parallel structures.
• Ring buffers and Streams/Priorities - It might be possible to have ring buffers to temporarily store events for potential replay. These buffers would not be exposed in any implementation.
• Ring buffer by high/medium/low priority: here the publisher determines where to temporarily store events based on Publisher determined potential relevance
• Ring buffer by named stream: might be more efficient in storing the right objects for the right amount of time. But what about replicated objects across streams? what about new and custom streams? Implementation might be complex.
• Datastore and/or YANG module name needs to be a valid entry for a filter. We need to provide guidance on filter conditions which need to added as syntax examples.
• This is another reason streams might be useful to standardize
• Balazs thinks that filtering on Metadata might be useful here. Alberto: does this make things more complex?

Proposal for Streams

Below in the table are some of the streams we discussed. I recommend that we define identities for #1 & #2 within 5277bis, augmented by #3 & #4 within yangpush, and possibly augmented by #5-#7 in a separate streams draft, and we could also add #8-#11 to that separate draft should OpState be adopted.

#	Stream type name	Current mapping practices	If OpState accepted, add additional stream mapping	when
1	netconf	Existing netconf notification stream	n/a	Now
2	custom-events	(vendor defines one or more of this stream type)	tbd	Now
3	yangpush	running + config=false objects	operational-state	Now
4	custom-yang	(vendor defines one or more of this stream type)	tbd	Now
5	config	running	config=true	streams draft
6	operational	config=false objects	config=false	streams draft
7	operational-no-counters	config=false objects + not-notifiable-on-change=true	config=false + not-notifiable-on-change=true	streams draft
8	running	n/a	running	if OpState adopted, streams draft
9	startup	n/a	startup	if OpState adopted, streams draft
10	intended	n/a	intended	if OpState adopted, streams draft
11	applied	n/a	applied	if OpState adopted, streams draft

Note 1: that we need to be careful about the definition and population of a #3 yangpush stream so that it maps closely to OpState's "operational-state".