--- 1/draft-ietf-i2rs-pub-sub-requirements-05.txt 2016-04-17 07:16:07.491515253 -0700 +++ 2/draft-ietf-i2rs-pub-sub-requirements-06.txt 2016-04-17 07:16:07.523516050 -0700 @@ -1,19 +1,19 @@ Interface to the Routing System (i2rs) E. Voit Internet-Draft A. Clemm Intended status: Informational A. Gonzalez Prieto -Expires: August 6, 2016 Cisco Systems - February 3, 2016 +Expires: October 17, 2016 Cisco Systems + April 15, 2016 Requirements for Subscription to YANG Datastores - draft-ietf-i2rs-pub-sub-requirements-05 + draft-ietf-i2rs-pub-sub-requirements-06 Abstract This document provides requirements for a service that allows client applications to subscribe to updates of a YANG datastore. Based on criteria negotiated as part of a subscription, updates will be pushed to targeted recipients. Such a capability eliminates the need for periodic polling of YANG datastores by applications and fills a functional gap in existing YANG transports (i.e. Netconf and Restconf). Such a service can be summarized as a "pub/sub" service @@ -30,158 +30,124 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on August 6, 2016. + This Internet-Draft will expire on October 17, 2016. Copyright Notice Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Business Drivers . . . . . . . . . . . . . . . . . . . . . . 3 - 2.1. Pub/Sub in I2RS . . . . . . . . . . . . . . . . . . . . . 4 + 2.1. Pub/Sub in I2RS . . . . . . . . . . . . . . . . . . . . . 3 2.2. Pub/Sub variants on Network Elements . . . . . . . . . . 5 - 2.3. Existing Generalized Pub/Sub Implementations . . . . . . 6 + 2.3. Existing Generalized Pub/Sub Implementations . . . . . . 5 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 - 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 8 - 4.1. Assumptions for Subscriber Behavior . . . . . . . . . . . 8 - 4.2. Subscription Service Requirements . . . . . . . . . . . . 8 - 4.2.1. General . . . . . . . . . . . . . . . . . . . . . . . 8 - 4.2.2. Negotiation . . . . . . . . . . . . . . . . . . . . . 10 - 4.2.3. Update Distribution . . . . . . . . . . . . . . . . . 10 - 4.2.4. Transport . . . . . . . . . . . . . . . . . . . . . . 11 + 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 7 + 4.1. Assumptions for Subscriber Behavior . . . . . . . . . . . 7 + 4.2. Subscription Service Requirements . . . . . . . . . . . . 7 + 4.2.1. General . . . . . . . . . . . . . . . . . . . . . . . 7 + 4.2.2. Negotiation . . . . . . . . . . . . . . . . . . . . . 9 + 4.2.3. Update Distribution . . . . . . . . . . . . . . . . . 9 + 4.2.4. Transport . . . . . . . . . . . . . . . . . . . . . . 10 4.2.5. Security Requirements . . . . . . . . . . . . . . . . 11 - 4.2.6. Subscription QoS . . . . . . . . . . . . . . . . . . 12 + 4.2.6. Subscription QoS . . . . . . . . . . . . . . . . . . 11 4.2.7. Filtering . . . . . . . . . . . . . . . . . . . . . . 13 - 4.2.8. Assurance and Monitoring . . . . . . . . . . . . . . 14 - 5. Security Considerations . . . . . . . . . . . . . . . . . . . 15 - 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 - 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 - 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 - 8.1. Normative References . . . . . . . . . . . . . . . . . . 15 - 8.2. Informative References . . . . . . . . . . . . . . . . . 16 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 + 4.2.8. Assurance and Monitoring . . . . . . . . . . . . . . 13 + 5. Security Considerations . . . . . . . . . . . . . . . . . . . 14 + 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 + 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 + 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 + 8.1. Normative References . . . . . . . . . . . . . . . . . . 14 + 8.2. Informative References . . . . . . . . . . . . . . . . . 15 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 1. Introduction - YANG has gained acceptance as the data definition language of choice - for control and management related information. Applications that - interact with YANG datastores are extending beyond traditional - configuration of network elements. In many cases these applications - are aimed at service-assurance, which involves monitoring of - operational data and state. The existing YANG technology ecosystem - is proving insufficient for those applications due to: - - o a reliance on RPC-style interactions where data is configured or - fetched on-demand by applications, and - - o change notifications which identify a node associated with the - config change, without the actual data updates. + Applications interacting with YANG datastores require capabilities + beyond the traditional client-server configuration of network + elements. One class of such applications are service-assurance + applications which must maintain a continuous view of operational + data and state. Another class of applications are security + applications which must continuously track changes made upon network + elements to ensure compliance to corporate policy. - Put simply, periodic fetching of data is not an adequate solution for + Periodic fetching of data is not an adequate solution for applications requiring frequent or prompt updates of remote object - state. Trying to impose a polling-based solution to this problem - imposes load on networks, devices, and applications. Additionally, - polling solutions are brittle in the face of communication glitches, - and they have limitations in their ability to synchronize and - calibrate retrieval intervals across a network. - - I2RS WG documents have expressed a need for more robust YANG object - subscriptions. Similar discussions are underway in NETMOD and - NETCONF. With the support of standards bodies such as OMG (DDS), - XMPP.org standard, generic Publication/Subscription (Pub/Sub) - mechanisms to communicate data updates have been defined and proven - themselves in a wide variety of deployments. - - It is time to incorporate such generic object subscription mechanisms - as part of Network Elements, and allow these mechanisms to be applied - in the context of data that is conceptually contained in YANG - datastores. With such mechanisms, applications on either a - controller or Network Element have access to a set of consistent - network information driven via push from peer Network Elements which - host authoritative information. - - There are some valid IETF starting points and contexts for these - mechanisms. For example NETCONF Event Notifications [RFC5277] - provides a useful tool for an end-to-end solution. However RFC5277 - does not follow the Pub/Sub paradigm, does not allow the explicit - deletion of subscriptions, and predates YANG. Predating YANG is an - issue, as monitoring and filtering based on YANG subtrees becomes - problematic. [RFC6470] defines configuration change notifications, - but does not provide the actual configuration change. + state. Applying polling-based solutions here imposes load on + networks, devices, and applications. Additionally, polling solutions + are brittle in the face of communication glitches, and have + limitations in their ability to synchronize and calibrate retrieval + intervals across a network. These limitations can be addressed by + including generic object subscription mechanisms within Network + Elements, and allowing these mechanisms to be applied in the context + of data that is conceptually contained in YANG datastores. - Because of this, the authors have put forward this requirement - document as well as [datastore-push]. We believe these provide a - context upon which to create new solutions. It is intended that - these documents include requirements and provide technologies - applicable beyond I2RS. + This document aggregates requirements for such subscription from a + variety of deployment scenarios. 2. Business Drivers For decades, information delivery of current network state has been accomplished either by fetching from operations interfaces, or via - dedicated, customized networking protocols. With the growth of SDN, - imperative policy distribution, and YANG's ascent as a dominant - programmatic interface to network elements, this mixture of fetch - plus custom networking protocols is no longer sufficient. What is - needed is a push mechanism that is able to deliver objects and object - changes as they happen. + dedicated, customized networking protocols. With the growth of + centralized orchestration infrastructures, imperative policy + distribution, and YANG's ascent as the dominant data modeling + language for use in programmatic interfaces to network elements, this + mixture of fetch plus custom networking protocols is no longer + sufficient. What is needed is a push mechanism that is able to + deliver object changes as they happen. These push distribution mechanisms will not replace existing networking protocols. Instead they will supplement these protocols, providing different response time, peering, scale, and security characteristics. - At the same time, SNMP and MIBs are still widely deployed and the - defacto choice for many monitoring solutions. Those solutions do not - require support for configuration transactions and the need to - validate and maintain configuration consistency, hence there is less - pressure to abandon SNMP and MIBs. Arguably the biggest shortcoming - of SNMP for those applications concerns the need to rely on periodic + Push solutions will not displace all existing operations + infrastructure needs. And SNMP and MIBs will remain widely deployed + and the defacto choice for many monitoring solutions. But some + functions could be displaced. Arguably the biggest shortcoming of + SNMP for those applications concerns the need to rely on periodic polling, because it introduces additional load on the network and - devices, is brittle in case polling cycles are missed, and is hard to - synchronize and calibrate across a network, making data obtained from - multiple devices less comparable. If applications need to apply - those same interaction patterns for YANG datastores, similar issues - can be expected. Migration to YANG datastores by applications that - do not have to worry about transactional integrity becomes a lot more - compelling if those issues are addressed. + devices, because it is brittle in case polling cycles are missed, and + because is hard to synchronize and calibrate across a network. If + applications can only use polling type interaction patterns with YANG + datastores, similar issues can be expected. 2.1. Pub/Sub in I2RS Various I2RS documents highlight the need to provide Pub/Sub capabilities between network elements. From [i2rs-arch], there are references throughout the document beginning in section 6.2. Some specific examples include: o section 7.6 provides high level pub/sub (notification) guidance - o section 6.4.2 identifies "subscribing to an information stream of route changes receiving notifications about peers coming up or going down" o section 6.3 notes that when local config preempts I2RS, external notification might be necessary In addition [i2rs-usecase] has relevant requirements. A small subset includes: @@ -222,46 +188,44 @@ receive a live stream of I2RS interactions in trace log format and could flexibly choose to do a number of things with the log messages 2.2. Pub/Sub variants on Network Elements This document is intended to cover requirements beyond I2RS. Looking at history, there are many examples of switching and routing protocols which have done explicit or implicit pub/sub in the past. In addition, new policy notification mechanisms which operate on - Switches and Routers are being specified now. A very small subset of - these includes: - - o Routing Adjacencies in MPLS VPNs [RFC6513] + Switches and Routers are being specified now. A small subset of + current and past subscriptions includes: - o OSPF Route Flooding [RFC2328] + o Multicast topology establishment is accomplished before any + content delivery is made to endpoints (IGMP, PIM, etc.) - o Multicast topology establishment protocols (IGMP, PIM, etc.) - o Audio-Video Bridging streams needing guaranteed latency - [AVB-latency] (802.1Q-2011 Clause 35) + o Secure Automation and Continuous Monitoring (SACM) allows + subscription into devices which then may push spontaneous changes + in their configured hardware and software[sacm-requirements] - o Secure Automation and Continuous Monitoring (SACM) - [sacm-requirements] + o In MPLS VPNs [RFC6513] a Customer Edge router exchanges PIM + control messages before PE Routing Adjacencies are passed. + [RFC6513] - o "Peer Mount" subscriptions for configuration verification between - peers[draft-voit-netmod] + o After OSPF establishes its adjacencies, Link State Advertisement + will then commence [RFC2328] - Worthy of note in the list above is the wide variety of broadcast, - multicast, and unicast transports used. In addition some transports - are at L3, and some at L2. Therefore if we are going to attempt a - generic Pub/Sub mechanism, it will need to be structured so that it - may support alternative transports. Looking at the nearer term based - on current I2RS requirements, NETCONF should be our transport - starting point as it supports connection-oriented/unicast - communication. But we need to be prepared to decouple where viable - to support Multicast and Broadcast distribution as well. + Worthy of note in the examples above is the wide variety of + underlying transports. A generalized Pub/Sub mechanism therefore + should be structured to support alternative transports. Based on + current I2RS requirements, NETCONF should the initially supported + transport based on the need for connection-oriented/unicast + communication. Eventual support Multicast and Broadcast subscription + update distribution will be needed as well. 2.3. Existing Generalized Pub/Sub Implementations TIBCO, RSS, CORBA, and other technologies all show precursor Pub/Sub technologies. However there are new needs described in Section 4 below which these technologies do not serve. We need a new pub-sub technology. There are at least two widely deployed generalized pub/sub implementations which come close to current needs: XMPP[XEP-0060] and @@ -289,24 +253,24 @@ A Receiver is the target to which a Publisher pushes updates. In general, the Receiver and Subscriber will be the same entity. A Subscription Service provides Subscriptions to Subscribers of YANG data. A Subscription Service interacts with the Publisher of the YANG data as needed to provide the data per the terms of the Subscription. A Subscription Request for one or more YANG subtrees (including - single leafs) made by the Subscriber of a Publisher and targeted to a - Receiver. A Subscription may include constraints which dictate how - often or under what conditions YANG information updates might be - sent. + single leafs) is made by the Subscriber of a Publisher and is + targeted to a Receiver. A Subscription may include constraints which + dictate how often or under what conditions YANG information updates + might be sent. A Subscription is a contract between a Subscription Service and a Subscriber that stipulates the data to be pushed and the associated terms. A YANG datastore is a conceptual datastore that contains hierarchical data defined in YANG data models. It is what is referred in existing RFCs as "NETCONF datastore". However, as the same datastore is no longer tied to NETCONF as a specific transport, the term "YANG datastore" is deemed more appropriate. @@ -426,21 +390,21 @@ A Subscription Service MAY offer the ability to modify a subscription filter. If such an ability is offered, the service MUST provide subscribers with an indication telling at what point the modified subscription goes into effect. 4.2.2. Negotiation A Subscription Service MUST be able to negotiate the following terms of a Subscription: - o The policy: i.e. whether updates are on-change of periodic + o The policy: i.e. whether updates are on-change or periodic o The interval, for periodic publication policy o The dampening period, for on-change update policy (if supported) o Any filters associated with a subtree subscription A Subscription Service SHOULD be able to negotiate QoS criteria for a Subscription. Examples of Subscription QoS criteria may include reliability of the Subscription Service, reaction time between a @@ -675,83 +639,58 @@ suggestions that were received from Ambika Tripathy and Prabhakara Yellai as well as the helpfulness of related end-to-end system context info from Nancy Cam Winget, Ken Beck, and David McGrew. 8. References 8.1. Normative References [i2rs-arch] Atlas, A., "An Architecture for the Interface to the - Routing System", December 2015, + Routing System", February 2016, . [i2rs-traceability] Clarke, J., Salgueiro, G., and C. Pignataro, "Interface to the Routing System (I2RS) Traceability: Framework and - Information Model", December 2015, + Information Model", February 2016, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, DOI 10.17487/RFC2328, April 1998, . - [RFC5277] Chisholm, S. and H. Trevino, "NETCONF Event - Notifications", RFC 5277, DOI 10.17487/RFC5277, July 2008, - . - - [RFC6470] Bierman, A., "Network Configuration Protocol (NETCONF) - Base Notifications", RFC 6470, DOI 10.17487/RFC6470, - February 2012, . - [RFC6513] Rosen, E., Ed. and R. Aggarwal, Ed., "Multicast in MPLS/ BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513, February 2012, . 8.2. Informative References - [AVB-latency] - Jeffree, T., "802.1Qav - Forwarding and Queuing - Enhancements for Time-Sensitive Streams", December 2009, - . - - [datastore-push] - Clemm, A., Gonzalez Prieto, A., and E. Voit, "Subscribing - to datastore push updates", October 2015, - . - - [draft-voit-netmod] - Voit, E., "Requirements for Peer Mounting of YANG subtrees - from Remote Datastores", September 2015, - . - [i2rs-usecase] Hares, S. and M. Chen, "Summary of I2RS Use Case - Requirements", November 2015, + Requirements", March 2016, . [OMG-DDS] "Data Distribution Service for Real-time Systems, version 1.2", January 2007, . [sacm-requirements] Cam Winget, N., "Secure Automation and Continuous - Monitoring (SACM) Requirements", July 2015, + Monitoring (SACM) Requirements", March 2016, . [XEP-0060] Millard, P., "XEP-0060: Publish-Subscribe", July 2010, . Authors' Addresses Eric Voit