Subject: [Netconf] Minutes 19-Oct: NETCONF/RESTCONF/HTTP2 Subscription & Event drafts

From: "Eric Voit (evoit)" <[email-masked]>
Date: Wed, 19 Oct 2016 21:14:17 +0000

Posted at:
https://github.com/netconf-wg/yang-push/wiki/Minutes-2016-10-19

Meeting Materials

Attending

WebEx Recording<https://cisco.webex.com/ciscosales/lsr.php?RCID=24a1b0cd50e449fea840c20c8b7686a9>
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?  We need a future session on filtering examples.

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: 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".