--- 1/draft-ietf-i2rs-pub-sub-requirements-07.txt 2016-05-13 09:19:57.801098691 -0700 +++ 2/draft-ietf-i2rs-pub-sub-requirements-08.txt 2016-05-13 09:19:57.905101291 -0700 @@ -1,28 +1,28 @@ Interface to the Routing System (i2rs) E. Voit Internet-Draft A. Clemm Intended status: Informational A. Gonzalez Prieto -Expires: November 5, 2016 Cisco Systems - May 4, 2016 +Expires: November 14, 2016 Cisco Systems + May 13, 2016 Requirements for Subscription to YANG Datastores - draft-ietf-i2rs-pub-sub-requirements-07 + draft-ietf-i2rs-pub-sub-requirements-08 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 + functional gap in existing YANG transports (i.e., Netconf and Restconf). Such a service can be summarized as a "pub/sub" service for YANG datastore updates. Beyond a set of basic requirements for the service, various refinements are addressed. These refinements include: periodicity of object updates, filtering out of objects underneath a requested a subtree, and delivery QoS guarantees. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. @@ -30,21 +30,21 @@ 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 November 5, 2016. + This Internet-Draft will expire on November 14, 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 @@ -52,40 +52,40 @@ 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 . . . . . . . . . . . . . . . . . . . . . 3 - 2.2. Pub/Sub variants on Network Elements . . . . . . . . . . 5 + 2.2. Pub/Sub Variants on Network Elements . . . . . . . . . . 5 2.3. Existing Generalized Pub/Sub Implementations . . . . . . 5 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 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.7. Filtering . . . . . . . . . . . . . . . . . . . . . . 13 4.2.8. Assurance and Monitoring . . . . . . . . . . . . . . 14 - 5. Security Considerations . . . . . . . . . . . . . . . . . . . 14 - 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 - 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 + 5. Security Considerations . . . . . . . . . . . . . . . . . . . 15 + 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 + 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 8.1. Normative References . . . . . . . . . . . . . . . . . . 15 - 8.2. Informative References . . . . . . . . . . . . . . . . . 15 + 8.2. Informative References . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 1. Introduction 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 @@ -182,21 +182,21 @@ And [i2rs-traceability] has Pub/Sub requirements listed in Section 7.4.3. o I2RS Agents should support publishing I2RS trace log information to that feed as described in [i2rs-arch]. Subscribers would then 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 +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 small subset of current and past subscription mechanisms includes: o Multicast topology establishment is accomplished before any content delivery is made to endpoints (IGMP, PIM, etc.) @@ -265,21 +265,21 @@ A Subscription Request for one or more YANG subtrees (including 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 datastore is defined in [RFC6241] and is not redefined here. + A datastore is defined in [RFC6241]. An Update provides object changes which have occurred within subscribed YANG subtree(s). An Update must include the current status of (data) node instances which according to any filtering are reportably different from the previously provided state. An Update may include a bundled set of ordered/sequential changes for a given object that have been made since the last update. A Filter contains evaluation criteria which are evaluated against YANG object(s) within a Subscription. There are two types of @@ -294,21 +294,21 @@ XMPP[XEP-0060] and DDS[OMG-DDS] requirements specifications. 4.1. Assumptions for Subscriber Behavior This document provides requirements for the Subscription Service. It does not define all the requirements for the Subscriber/Receiver. However in order to frame the desired behavior of the Subscription Service, it is important to specify key input constraints. A Subscriber SHOULD avoid attempting to establish multiple - Subscriptions pertaining to the same information, i.e. referring to + Subscriptions pertaining to the same information, i.e., referring to the same datastore YANG subtrees. A Subscriber MAY provide Subscription QoS criteria to the Subscription Service; if the Subscription Service is unable to meet those criteria, the Subscription SHOULD NOT be established. When a Subscriber and Receiver are the same entity and the transport session is lost/terminated, the Subscriber MUST reestablish any subscriptions it previously created via signalling over the transport session. I.e., There is no requirement for the life span of such @@ -386,25 +386,26 @@ 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 or 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 The on-change policy dampening period (if the on-change policy is + 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 monitored YANG subtree/object change and a corresponding notification push, and the Subscription Service's ability to support certain levels of object liveliness. @@ -453,45 +454,64 @@ The sending of an Update MUST NOT occur before the dampening period expires for any enclosed object changes. A Subscription Service MAY, as an option, support a replay capability so that a set of updates generated during a previous time internal can be sent to a Receiver. 4.2.4. Transport + It is possible for updates coming from a Subscription Service to be + pushed over different types of transports such as NETCONF, RESTCONF, + and HTTP. Beyond existing transports, this Subsription Service will + applicable for emerging protocols such as those being defined in + [i2rs-usecase]. The need for such transport flexibility drives the + following requirements. + A Subscription Service SHOULD support different transports. A Subscription Service SHOULD support different encodings of payload. It MUST be possible for Receivers to associate the update with a specific Subscription. In the case of connection-oriented transport, when a transport connection drops, the associated Subscription SHOULD be terminated. It is up the Subscriber to request a new Subscription. 4.2.5. Security Requirements + Some uses of this Subscription Service will push privacy-sensitive + updates and metadata. Good deployment practices will bind this + generated information within secure, encrypted transport layer + mechanisms. For example if NETCONF is used as transport, then + [RFC5539] would be a valid option to secure the transported + information. The Subscription Service can also be used with emerging + deployment contexts as well. As an example, deployments based on + [i2rs-usecase] can apply these requirements in conjunction with those + documented within [i2rs-protocol-security] to secure ephemeral state + information being pushed from a Network Element. + As part of the Subscription establishment, there MUST be mutual authentication between the Subscriber and the Subscription Service. When there are multiple Subscribers, it SHOULD be possible to provide cryptographic authentication in such a way that no Subscriber can pose as the original Subscription Service. - Versioning MUST be supported so that the capabilities and behaviors - expected of specific technology implementations can be exposed. + Versioning of any subscription protocols MUST be supported so that + the capabilities and behaviors expected of specific technology + implementations can be exposed. - A Subscription could be used to attempt to retrieve information that - a client has not authorized access to. Therefore it is important + A Subscription could be used to attempt to retrieve information to + which a client has no authorized access. Therefore it is important that data pushed based on Subscriptions is authorized in the same way that regular data retrieval operations are authorized. Data being pushed to a client MUST be filtered accordingly, just like if the data were being retrieved on-demand. For Unicast transports, the NETCONF Authorization Control Model applies. Additions or changes within a subscribed subtree structure MUST be validated against authorization methods before Subscription Updates including new subtree information are pushed. @@ -573,23 +593,24 @@ The Subscription Service SHOULD be able to delay Updates on object push for a configurable period per Subscriber. It MUST be possible for an administrative entity to determine the Push latency between object change in a monitored subtree and the Subscription Service Push of the update transmission. 4.2.6.8. Relative Priority - The Subscription Service SHOULD include the relative priority of push - updates so that dequeuing and discarding of case of limited bandwidth - between Publisher and + The Subscription Service SHOULD support the relative prioritization + of Subscriptions so that dequeuing and discarding of push updates can + consider this if there is insufficient bandwidth between Publisher + and Receiver. 4.2.7. Filtering If no filtering criteria are provided, or if filtering criteria are met, updates for a subscribed object MUST be pushed, subject to the QoS limits established for the subscription. It MUST be possible for the Subscription Service to receive Filter(s) from a Subscriber and apply them to corresponding object(s) within a Subscription. @@ -647,21 +667,21 @@ 5. Security Considerations There are no additional security considerations beyond the requirements listed in Section 4.2.5. 6. IANA Considerations This document has no actions for IANA. -7. Acknowledgements +7. Acknowledgments We wish to acknowledge the helpful contributions, comments, and 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 @@ -680,31 +700,41 @@ [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, . + [RFC5539] Badra, M., "NETCONF over Transport Layer Security (TLS)", + RFC 5539, DOI 10.17487/RFC5539, May 2009, + . + [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., and A. Bierman, Ed., "Network Configuration Protocol (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, . [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 + [i2rs-protocol-security] + Hares, S., Migault, D., and J. Halpern, "I2RS Security + Related Requirements", May 2016, + . + [i2rs-usecase] Hares, S. and M. Chen, "Summary of I2RS Use Case Requirements", March 2016, . [OMG-DDS] "Data Distribution Service for Real-time Systems, version 1.2", January 2007, . [sacm-requirements]