1 / 11

Notification + Yang-push Kickoff

Notification + Yang-push Kickoff. 26 - April - 2016. Attendees (i.e., potential authors). Andy Bierman – YumaWorks Sharon Chisholm – Ciena Alexander Clemm – Cisco Einar Nilsen-Nygaard – Cisco Yan Gang - Huawei Alberto Gonzalez Prieto – Cisco Hector Trevino – Cisco

mariellam
Download Presentation

Notification + Yang-push Kickoff

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Notification + Yang-pushKickoff 26 - April - 2016

  2. Attendees (i.e., potential authors) • Andy Bierman – YumaWorks • Sharon Chisholm – Ciena • Alexander Clemm – Cisco • Einar Nilsen-Nygaard – Cisco • Yan Gang - Huawei • Alberto Gonzalez Prieto – Cisco • Hector Trevino – Cisco • Ambika Prasad Tripathy – Cisco • Eric Voit – Cisco • Kent Watsen – Juniper • Guangying Zheng (Walker) – Huawei

  3. Interests and Objectives What do each of us consider success? • Sharon: Relationship with existing RESTCONF notification mechanisms • Andy: Modularity so that solutions can be used/reused for different protocols. From SDN to IOT to COAP. Keep transport, encoding modularized. • Kent: High Throughput support (Control & data plane), backwards compatibility, OpenConfig & I2RS. • Einar: +1 w/ Andy & Kent goals. • Alex: +1 w/ Andy & Kent goals. Streaming updates is main objective, but modular • Yan: Performance in an SDN scenario (reaction speed & volume) • Walker: design of Notifications and support of new capabilities, ensure full functionality • Hector: evolution of NETCONF Notifications and Data Model separation. Coverage of Operational side. • Ambika: +1 w/ Andy & Kent goals. Modular, flexible, high throughput. Multi-tenancy. • Eric: +1 w/ Andy & Kent goals. Add in: native HTTP transport, micro-subscriptions.

  4. Assumptions • Everything is negotiable, assuming objective is under NETCONF charter • No assumption that existing drafts drive final result • IF/WHEN we get consensus on functional partitioning, fodder from existing drafts and other attendee materials should be applied as starting point (if applicable) • Attendees can be on zero-to-all drafts (tbd based on previous + new contribution.) • Must support 5277 backwards compatibility (note: this was revisited later in the call)

  5. Strawman functional partitioning context(as discussed at IETF95) Discussion: • Is this a reasonable starting point? (expecting lots of iteration on boundaries as this evolves.)

  6. Strawman Functional Partitioning Context(overlaid with IETF95 authors’ mental model) Subscription Transport Legend Compatibility with RFC-5277

  7. Strawman Functional Partitioning Context(more details on authors’ mental model) • YANG Datastore Push (includes functions above Base Subscription Draft): • Datastore on-change and periodic triggers • YANG filters per RFC6241 • Authorization model per object • Push-update, Push-change-update • New stream types & stuff • Subscriptions for Event Notifications (Base Subscription Draft) • Support for many subscriptions / transport • Dynamic & Static state machines • Stream discovery • New stream types (syslog?) • Authorization model per stream • RFC5277 & XPATH filters • RPCs: Establish, modify, delete • Error responses (under error-info?) • Notifications: started, suspended, resumed, terminated, modified • Negotiation • Stream configuration & stuff • Data Plane Notification • 5277 mode & YANG model • Multiple static receivers • Replay (by Stream type) • Prioritization • Monitoring • NETCONF Transport for Event Notifications • Transport mapping • 5277 mode • RESTCONF Transport for Event Notifications • Transport mappings (incl. HTTP2) • Subscriber/receiver different • Heartbeats and clean-up • Subscription to HTTP2 stream Out of Scope/future: dynamic stream creation, new undefined filter types

  8. Draft, document, and issue repository • Github repository corresponding to each partitioned context • Exposure of issues so all in WG can track. • Any Common terminology, context, and supporting materials maintained in a single Github Repository • Recommend “Subscriptions for Event Notifications” • Other suggestions/tools to use?

  9. Strawman Terms Page 1

  10. Strawman Terms Page 2

  11. Discussions • Thoughts on the partitioning context. Are we ok with each mapped to a strawman draft? • Who wants to be involved in which areas? • How to we structure meetings going forward? • Weekly by draft ? • Bi weekly cross-draft get-togethers/reviews?

More Related