draft-ietf-i2rs-pub-sub-requirements-07.txt   draft-ietf-i2rs-pub-sub-requirements-08.txt 
Interface to the Routing System (i2rs) E. Voit Interface to the Routing System (i2rs) E. Voit
Internet-Draft A. Clemm Internet-Draft A. Clemm
Intended status: Informational A. Gonzalez Prieto Intended status: Informational A. Gonzalez Prieto
Expires: November 5, 2016 Cisco Systems Expires: November 14, 2016 Cisco Systems
May 4, 2016 May 13, 2016
Requirements for Subscription to YANG Datastores Requirements for Subscription to YANG Datastores
draft-ietf-i2rs-pub-sub-requirements-07 draft-ietf-i2rs-pub-sub-requirements-08
Abstract Abstract
This document provides requirements for a service that allows client This document provides requirements for a service that allows client
applications to subscribe to updates of a YANG datastore. Based on applications to subscribe to updates of a YANG datastore. Based on
criteria negotiated as part of a subscription, updates will be pushed criteria negotiated as part of a subscription, updates will be pushed
to targeted recipients. Such a capability eliminates the need for to targeted recipients. Such a capability eliminates the need for
periodic polling of YANG datastores by applications and fills a 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 Restconf). Such a service can be summarized as a "pub/sub" service
for YANG datastore updates. Beyond a set of basic requirements for for YANG datastore updates. Beyond a set of basic requirements for
the service, various refinements are addressed. These refinements the service, various refinements are addressed. These refinements
include: periodicity of object updates, filtering out of objects include: periodicity of object updates, filtering out of objects
underneath a requested a subtree, and delivery QoS guarantees. underneath a requested a subtree, and delivery QoS guarantees.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
skipping to change at page 1, line 41 skipping to change at page 1, line 41
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." 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 Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 17 skipping to change at page 2, line 17
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Business Drivers . . . . . . . . . . . . . . . . . . . . . . 3 2. Business Drivers . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Pub/Sub in I2RS . . . . . . . . . . . . . . . . . . . . . 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 2.3. Existing Generalized Pub/Sub Implementations . . . . . . 5
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 7 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 7
4.1. Assumptions for Subscriber Behavior . . . . . . . . . . . 7 4.1. Assumptions for Subscriber Behavior . . . . . . . . . . . 7
4.2. Subscription Service Requirements . . . . . . . . . . . . 7 4.2. Subscription Service Requirements . . . . . . . . . . . . 7
4.2.1. General . . . . . . . . . . . . . . . . . . . . . . . 7 4.2.1. General . . . . . . . . . . . . . . . . . . . . . . . 7
4.2.2. Negotiation . . . . . . . . . . . . . . . . . . . . . 9 4.2.2. Negotiation . . . . . . . . . . . . . . . . . . . . . 9
4.2.3. Update Distribution . . . . . . . . . . . . . . . . . 9 4.2.3. Update Distribution . . . . . . . . . . . . . . . . . 9
4.2.4. Transport . . . . . . . . . . . . . . . . . . . . . . 10 4.2.4. Transport . . . . . . . . . . . . . . . . . . . . . . 10
4.2.5. Security Requirements . . . . . . . . . . . . . . . . 11 4.2.5. Security Requirements . . . . . . . . . . . . . . . . 11
4.2.6. Subscription QoS . . . . . . . . . . . . . . . . . . 12 4.2.6. Subscription QoS . . . . . . . . . . . . . . . . . . 12
4.2.7. Filtering . . . . . . . . . . . . . . . . . . . . . . 13 4.2.7. Filtering . . . . . . . . . . . . . . . . . . . . . . 13
4.2.8. Assurance and Monitoring . . . . . . . . . . . . . . 14 4.2.8. Assurance and Monitoring . . . . . . . . . . . . . . 14
5. Security Considerations . . . . . . . . . . . . . . . . . . . 14 5. Security Considerations . . . . . . . . . . . . . . . . . . . 15
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
8.1. Normative References . . . . . . . . . . . . . . . . . . 15 8.1. Normative References . . . . . . . . . . . . . . . . . . 15
8.2. Informative References . . . . . . . . . . . . . . . . . 15 8.2. Informative References . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
1. Introduction 1. Introduction
Applications interacting with YANG datastores require capabilities Applications interacting with YANG datastores require capabilities
beyond the traditional client-server configuration of network beyond the traditional client-server configuration of network
elements. One class of such applications are service-assurance elements. One class of such applications are service-assurance
applications which must maintain a continuous view of operational applications which must maintain a continuous view of operational
data and state. Another class of applications are security data and state. Another class of applications are security
applications which must continuously track changes made upon network applications which must continuously track changes made upon network
skipping to change at page 5, line 5 skipping to change at page 5, line 5
And [i2rs-traceability] has Pub/Sub requirements listed in And [i2rs-traceability] has Pub/Sub requirements listed in
Section 7.4.3. Section 7.4.3.
o I2RS Agents should support publishing I2RS trace log information o I2RS Agents should support publishing I2RS trace log information
to that feed as described in [i2rs-arch]. Subscribers would then to that feed as described in [i2rs-arch]. Subscribers would then
receive a live stream of I2RS interactions in trace log format and receive a live stream of I2RS interactions in trace log format and
could flexibly choose to do a number of things with the log could flexibly choose to do a number of things with the log
messages 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 This document is intended to cover requirements beyond I2RS. Looking
at history, there are many examples of switching and routing at history, there are many examples of switching and routing
protocols which have done explicit or implicit pub/sub in the past. protocols which have done explicit or implicit pub/sub in the past.
In addition, new policy notification mechanisms which operate on In addition, new policy notification mechanisms which operate on
switches and routers are being specified now. A small subset of switches and routers are being specified now. A small subset of
current and past subscription mechanisms includes: current and past subscription mechanisms includes:
o Multicast topology establishment is accomplished before any o Multicast topology establishment is accomplished before any
content delivery is made to endpoints (IGMP, PIM, etc.) content delivery is made to endpoints (IGMP, PIM, etc.)
skipping to change at page 6, line 40 skipping to change at page 6, line 40
A Subscription Request for one or more YANG subtrees (including A Subscription Request for one or more YANG subtrees (including
single leafs) is made by the Subscriber of a Publisher and is single leafs) is made by the Subscriber of a Publisher and is
targeted to a Receiver. A Subscription may include constraints which targeted to a Receiver. A Subscription may include constraints which
dictate how often or under what conditions YANG information updates dictate how often or under what conditions YANG information updates
might be sent. might be sent.
A Subscription is a contract between a Subscription Service and a A Subscription is a contract between a Subscription Service and a
Subscriber that stipulates the data to be pushed and the associated Subscriber that stipulates the data to be pushed and the associated
terms. 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 An Update provides object changes which have occurred within
subscribed YANG subtree(s). An Update must include the current subscribed YANG subtree(s). An Update must include the current
status of (data) node instances which according to any filtering are status of (data) node instances which according to any filtering are
reportably different from the previously provided state. An Update reportably different from the previously provided state. An Update
may include a bundled set of ordered/sequential changes for a given may include a bundled set of ordered/sequential changes for a given
object that have been made since the last update. object that have been made since the last update.
A Filter contains evaluation criteria which are evaluated against A Filter contains evaluation criteria which are evaluated against
YANG object(s) within a Subscription. There are two types of YANG object(s) within a Subscription. There are two types of
skipping to change at page 7, line 21 skipping to change at page 7, line 21
XMPP[XEP-0060] and DDS[OMG-DDS] requirements specifications. XMPP[XEP-0060] and DDS[OMG-DDS] requirements specifications.
4.1. Assumptions for Subscriber Behavior 4.1. Assumptions for Subscriber Behavior
This document provides requirements for the Subscription Service. It This document provides requirements for the Subscription Service. It
does not define all the requirements for the Subscriber/Receiver. does not define all the requirements for the Subscriber/Receiver.
However in order to frame the desired behavior of the Subscription However in order to frame the desired behavior of the Subscription
Service, it is important to specify key input constraints. Service, it is important to specify key input constraints.
A Subscriber SHOULD avoid attempting to establish multiple 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. the same datastore YANG subtrees.
A Subscriber MAY provide Subscription QoS criteria to the A Subscriber MAY provide Subscription QoS criteria to the
Subscription Service; if the Subscription Service is unable to meet Subscription Service; if the Subscription Service is unable to meet
those criteria, the Subscription SHOULD NOT be established. those criteria, the Subscription SHOULD NOT be established.
When a Subscriber and Receiver are the same entity and the transport When a Subscriber and Receiver are the same entity and the transport
session is lost/terminated, the Subscriber MUST reestablish any session is lost/terminated, the Subscriber MUST reestablish any
subscriptions it previously created via signalling over the transport subscriptions it previously created via signalling over the transport
session. I.e., There is no requirement for the life span of such session. I.e., There is no requirement for the life span of such
skipping to change at page 9, line 18 skipping to change at page 9, line 18
A Subscription Service MAY offer the ability to modify a subscription A Subscription Service MAY offer the ability to modify a subscription
Filter. If such an ability is offered, the service MUST provide Filter. If such an ability is offered, the service MUST provide
subscribers with an indication telling at what point the modified subscribers with an indication telling at what point the modified
subscription goes into effect. subscription goes into effect.
4.2.2. Negotiation 4.2.2. Negotiation
A Subscription Service MUST be able to negotiate the following terms A Subscription Service MUST be able to negotiate the following terms
of a Subscription: 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 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 o Any Filters associated with a subtree subscription
A Subscription Service SHOULD be able to negotiate QoS criteria for a A Subscription Service SHOULD be able to negotiate QoS criteria for a
Subscription. Examples of Subscription QoS criteria may include Subscription. Examples of Subscription QoS criteria may include
reliability of the Subscription Service, reaction time between a reliability of the Subscription Service, reaction time between a
monitored YANG subtree/object change and a corresponding notification monitored YANG subtree/object change and a corresponding notification
push, and the Subscription Service's ability to support certain push, and the Subscription Service's ability to support certain
levels of object liveliness. levels of object liveliness.
skipping to change at page 10, line 38 skipping to change at page 10, line 38
The sending of an Update MUST NOT occur before the dampening period The sending of an Update MUST NOT occur before the dampening period
expires for any enclosed object changes. expires for any enclosed object changes.
A Subscription Service MAY, as an option, support a replay capability A Subscription Service MAY, as an option, support a replay capability
so that a set of updates generated during a previous time internal so that a set of updates generated during a previous time internal
can be sent to a Receiver. can be sent to a Receiver.
4.2.4. Transport 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 transports.
A Subscription Service SHOULD support different encodings of payload. A Subscription Service SHOULD support different encodings of payload.
It MUST be possible for Receivers to associate the update with a It MUST be possible for Receivers to associate the update with a
specific Subscription. specific Subscription.
In the case of connection-oriented transport, when a transport In the case of connection-oriented transport, when a transport
connection drops, the associated Subscription SHOULD be terminated. connection drops, the associated Subscription SHOULD be terminated.
It is up the Subscriber to request a new Subscription. It is up the Subscriber to request a new Subscription.
4.2.5. Security Requirements 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 As part of the Subscription establishment, there MUST be mutual
authentication between the Subscriber and the Subscription Service. authentication between the Subscriber and the Subscription Service.
When there are multiple Subscribers, it SHOULD be possible to provide When there are multiple Subscribers, it SHOULD be possible to provide
cryptographic authentication in such a way that no Subscriber can cryptographic authentication in such a way that no Subscriber can
pose as the original Subscription Service. pose as the original Subscription Service.
Versioning MUST be supported so that the capabilities and behaviors Versioning of any subscription protocols MUST be supported so that
expected of specific technology implementations can be exposed. the capabilities and behaviors expected of specific technology
implementations can be exposed.
A Subscription could be used to attempt to retrieve information that A Subscription could be used to attempt to retrieve information to
a client has not authorized access to. Therefore it is important which a client has no authorized access. Therefore it is important
that data pushed based on Subscriptions is authorized in the same way that data pushed based on Subscriptions is authorized in the same way
that regular data retrieval operations are authorized. Data being that regular data retrieval operations are authorized. Data being
pushed to a client MUST be filtered accordingly, just like if the pushed to a client MUST be filtered accordingly, just like if the
data were being retrieved on-demand. For Unicast transports, the data were being retrieved on-demand. For Unicast transports, the
NETCONF Authorization Control Model applies. NETCONF Authorization Control Model applies.
Additions or changes within a subscribed subtree structure MUST be Additions or changes within a subscribed subtree structure MUST be
validated against authorization methods before Subscription Updates validated against authorization methods before Subscription Updates
including new subtree information are pushed. including new subtree information are pushed.
skipping to change at page 13, line 23 skipping to change at page 13, line 39
The Subscription Service SHOULD be able to delay Updates on object The Subscription Service SHOULD be able to delay Updates on object
push for a configurable period per Subscriber. push for a configurable period per Subscriber.
It MUST be possible for an administrative entity to determine the It MUST be possible for an administrative entity to determine the
Push latency between object change in a monitored subtree and the Push latency between object change in a monitored subtree and the
Subscription Service Push of the update transmission. Subscription Service Push of the update transmission.
4.2.6.8. Relative Priority 4.2.6.8. Relative Priority
The Subscription Service SHOULD include the relative priority of push The Subscription Service SHOULD support the relative prioritization
updates so that dequeuing and discarding of case of limited bandwidth of Subscriptions so that dequeuing and discarding of push updates can
between Publisher and consider this if there is insufficient bandwidth between Publisher
and Receiver.
4.2.7. Filtering 4.2.7. Filtering
If no filtering criteria are provided, or if filtering criteria are If no filtering criteria are provided, or if filtering criteria are
met, updates for a subscribed object MUST be pushed, subject to the met, updates for a subscribed object MUST be pushed, subject to the
QoS limits established for the subscription. QoS limits established for the subscription.
It MUST be possible for the Subscription Service to receive Filter(s) It MUST be possible for the Subscription Service to receive Filter(s)
from a Subscriber and apply them to corresponding object(s) within a from a Subscriber and apply them to corresponding object(s) within a
Subscription. Subscription.
skipping to change at page 15, line 5 skipping to change at page 15, line 15
5. Security Considerations 5. Security Considerations
There are no additional security considerations beyond the There are no additional security considerations beyond the
requirements listed in Section 4.2.5. requirements listed in Section 4.2.5.
6. IANA Considerations 6. IANA Considerations
This document has no actions for IANA. This document has no actions for IANA.
7. Acknowledgements 7. Acknowledgments
We wish to acknowledge the helpful contributions, comments, and We wish to acknowledge the helpful contributions, comments, and
suggestions that were received from Ambika Tripathy and Prabhakara suggestions that were received from Ambika Tripathy and Prabhakara
Yellai as well as the helpfulness of related end-to-end system Yellai as well as the helpfulness of related end-to-end system
context info from Nancy Cam Winget, Ken Beck, and David McGrew. context info from Nancy Cam Winget, Ken Beck, and David McGrew.
8. References 8. References
8.1. Normative References 8.1. Normative References
skipping to change at page 15, line 38 skipping to change at page 15, line 48
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328,
DOI 10.17487/RFC2328, April 1998, DOI 10.17487/RFC2328, April 1998,
<http://www.rfc-editor.org/info/rfc2328>. <http://www.rfc-editor.org/info/rfc2328>.
[RFC5539] Badra, M., "NETCONF over Transport Layer Security (TLS)",
RFC 5539, DOI 10.17487/RFC5539, May 2009,
<http://www.rfc-editor.org/info/rfc5539>.
[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
and A. Bierman, Ed., "Network Configuration Protocol and A. Bierman, Ed., "Network Configuration Protocol
(NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
<http://www.rfc-editor.org/info/rfc6241>. <http://www.rfc-editor.org/info/rfc6241>.
[RFC6513] Rosen, E., Ed. and R. Aggarwal, Ed., "Multicast in MPLS/ [RFC6513] Rosen, E., Ed. and R. Aggarwal, Ed., "Multicast in MPLS/
BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513, February BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513, February
2012, <http://www.rfc-editor.org/info/rfc6513>. 2012, <http://www.rfc-editor.org/info/rfc6513>.
8.2. Informative References 8.2. Informative References
[i2rs-protocol-security]
Hares, S., Migault, D., and J. Halpern, "I2RS Security
Related Requirements", May 2016,
<https://datatracker.ietf.org/doc/draft-ietf-i2rs-
protocol-security-requirements/>.
[i2rs-usecase] [i2rs-usecase]
Hares, S. and M. Chen, "Summary of I2RS Use Case Hares, S. and M. Chen, "Summary of I2RS Use Case
Requirements", March 2016, Requirements", March 2016,
<https://datatracker.ietf.org/doc/draft-ietf-i2rs-usecase- <https://datatracker.ietf.org/doc/draft-ietf-i2rs-usecase-
reqs-summary/>. reqs-summary/>.
[OMG-DDS] "Data Distribution Service for Real-time Systems, version [OMG-DDS] "Data Distribution Service for Real-time Systems, version
1.2", January 2007, <http://www.omg.org/spec/DDS/1.2/>. 1.2", January 2007, <http://www.omg.org/spec/DDS/1.2/>.
[sacm-requirements] [sacm-requirements]
 End of changes. 20 change blocks. 
23 lines changed or deleted 54 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/