idnits 2.17.1
draft-ietf-i2rs-pub-sub-requirements-04.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
No issues found here.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the IETF Trust and authors Copyright Line does not
match the current year
-- The document date (January 4, 2016) is 3027 days in the past. Is this
intentional?
Checking references for intended status: Proposed Standard
----------------------------------------------------------------------------
(See RFCs 3967 and 4897 for information about using normative references
to lower-maturity documents in RFCs)
No issues found here.
Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 Interface to the Routing System (i2rs) E. Voit
3 Internet-Draft A. Clemm
4 Intended status: Standards Track A. Gonzalez Prieto
5 Expires: July 7, 2016 Cisco Systems
6 January 4, 2016
8 Requirements for Subscription to YANG Datastores
9 draft-ietf-i2rs-pub-sub-requirements-04
11 Abstract
13 This document provides requirements for a service that allows client
14 applications to subscribe to updates of a YANG datastore. Based on
15 criteria negotiated as part of a subscription, updates will be pushed
16 to targeted recipients. Such a capability eliminates the need for
17 periodic polling of YANG datastores by applications and fills a
18 functional gap in existing YANG transports (i.e. Netconf and
19 Restconf). Such a service can be summarized as a "pub/sub" service
20 for YANG datastore updates. Beyond a set of basic requirements for
21 the service, various refinements are addressed. These refinements
22 include: periodicity of object updates, filtering out of objects
23 underneath a requested a subtree, and delivery QoS guarantees.
25 Status of This Memo
27 This Internet-Draft is submitted in full conformance with the
28 provisions of BCP 78 and BCP 79.
30 Internet-Drafts are working documents of the Internet Engineering
31 Task Force (IETF). Note that other groups may also distribute
32 working documents as Internet-Drafts. The list of current Internet-
33 Drafts is at http://datatracker.ietf.org/drafts/current/.
35 Internet-Drafts are draft documents valid for a maximum of six months
36 and may be updated, replaced, or obsoleted by other documents at any
37 time. It is inappropriate to use Internet-Drafts as reference
38 material or to cite them other than as "work in progress."
40 This Internet-Draft will expire on July 7, 2016.
42 Copyright Notice
44 Copyright (c) 2016 IETF Trust and the persons identified as the
45 document authors. All rights reserved.
47 This document is subject to BCP 78 and the IETF Trust's Legal
48 Provisions Relating to IETF Documents
49 (http://trustee.ietf.org/license-info) in effect on the date of
50 publication of this document. Please review these documents
51 carefully, as they describe your rights and restrictions with respect
52 to this document. Code Components extracted from this document must
53 include Simplified BSD License text as described in Section 4.e of
54 the Trust Legal Provisions and are provided without warranty as
55 described in the Simplified BSD License.
57 Table of Contents
59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
60 2. Business Drivers . . . . . . . . . . . . . . . . . . . . . . 3
61 2.1. Pub/Sub in I2RS . . . . . . . . . . . . . . . . . . . . . 4
62 2.2. Pub/Sub variants on Network Elements . . . . . . . . . . 5
63 2.3. Existing Generalized Pub/Sub Implementations . . . . . . 6
64 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
65 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 8
66 4.1. Assumptions for Subscriber Behavior . . . . . . . . . . . 8
67 4.2. Subscription Service Requirements . . . . . . . . . . . . 8
68 4.2.1. General . . . . . . . . . . . . . . . . . . . . . . . 8
69 4.2.2. Negotiation . . . . . . . . . . . . . . . . . . . . . 10
70 4.2.3. Update Distribution . . . . . . . . . . . . . . . . . 10
71 4.2.4. Transport . . . . . . . . . . . . . . . . . . . . . . 11
72 4.2.5. Security Requirements . . . . . . . . . . . . . . . . 11
73 4.2.6. Subscription QoS . . . . . . . . . . . . . . . . . . 12
74 4.2.7. Filtering . . . . . . . . . . . . . . . . . . . . . . 13
75 4.2.8. Assurance and Monitoring . . . . . . . . . . . . . . 14
76 5. Security Considerations . . . . . . . . . . . . . . . . . . . 15
77 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
78 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15
79 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
80 8.1. Normative References . . . . . . . . . . . . . . . . . . 15
81 8.2. Informative References . . . . . . . . . . . . . . . . . 16
82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17
84 1. Introduction
86 YANG has gained acceptance as the data definition language of choice
87 for control and management related information. Applications that
88 interact with YANG datastores are extending beyond traditional
89 configuration of network elements. In many cases these applications
90 are aimed at service-assurance, which involves monitoring of
91 operational data and state. The existing YANG technology ecosystem
92 is proving insufficient for those applications due to:
94 o a reliance on RPC-style interactions where data is configured or
95 fetched on-demand by applications, and
97 o change notifications which identify a node associated with the
98 config change, without the actual data updates.
100 Put simply, periodic fetching of data is not an adequate solution for
101 applications requiring frequent or prompt updates of remote object
102 state. Trying to impose a polling based solution to this problem
103 imposes load on networks, devices, and applications. Additionally,
104 polling solutions are brittle in the face of communication glitches,
105 and they have limitations in their ability to synchronize and
106 calibrate retrieval intervals across a network.
108 I2RS WG documents have expressed a need for more robust YANG object
109 subscriptions. Similar discussions are underway in NETMOD and
110 NETCONF. With the support of standards bodies such as OMG (DDS),
111 XMPP.org standard, generic Pub/Sub mechanisms to communicate data
112 updates have been defined and proven themselves in a wide variety of
113 deployments.
115 It is time to incorporate such generic object subscription mechanisms
116 as part of Network Elements, and allow these mechanisms to be applied
117 in the context of data that is conceptually contained in YANG
118 datastores. With such mechanisms, both controller and local Network
119 Element based applications can have access to a set of consistent
120 network information driven via push from peer Network Elements which
121 host authoritative information.
123 There are some valid IETF starting points and contexts for these
124 mechanisms. For example NETCONF Event Notifications [RFC5277]
125 provides a useful tool for an end-to-end solution. However RFC5277
126 does not follow the Pub/Sub paradigm, does not allow the explicit
127 deletion of subscriptions, and predates YANG. Predating YANG is an
128 issue, as monitoring and filtering based on YANG subtrees becomes
129 problematic. [RFC6470] defines configuration change notifications,
130 but doesn't provide the actual configuration change.
132 Because of this, the authors have put forward this requirements
133 document as well as [datastore-push]. We believe these provide a
134 context upon which to create new solution. It is intended that these
135 documents include requirements and provide technologies applicable
136 beyond I2RS.
138 2. Business Drivers
140 For decades, information delivery of current network state has been
141 accomplished either by fetching from operations interfaces, or via
142 dedicated, customized networking protocols. With the growth of SDN,
143 imperative policy distribution, and YANG's ascent as a dominant
144 programmatic interface to network elements, this mixture of fetch
145 plus custom networking protocols is no longer sufficient. What is
146 needed is a push mechanism that is able to deliver objects and object
147 changes as they happen.
149 These push distribution mechanisms will not replace existing
150 networking protocols. Instead they will supplement these protocols,
151 providing different response time, peering, scale, and security
152 characteristics.
154 At the same time, SNMP and MIBs are still widely deployed and the
155 defacto choice for many monitoring solutions. Those solutions do not
156 require support for configuration transactions and the need to
157 validate and maintain configuration consistency, hence there is less
158 pressure to abandon SNMP and MIBs. Arguably the biggest shortcoming
159 of SNMP for those applications concerns the need to rely on periodic
160 polling, because it introduces additional load on the network and
161 devices, is brittle in case polling cycles are missed, and is hard to
162 synchronize and calibrate across a network, making data obtained from
163 multiple devices less comparable. If applications need to apply
164 those same interaction patterns for YANG datastores, similar issues
165 can be expected. Migration to YANG datastores by applications that
166 do not have to worry about transactional integrity becomes a lot more
167 compelling if those issues are addressed.
169 2.1. Pub/Sub in I2RS
171 Various I2RS documents highlight the need to provide Pub/Sub
172 capabilities between network elements. From [i2rs-arch], there are
173 references throughout the document beginning in section 6.2. Some
174 specific examples include:
176 o section 7.6 provides high level pub/sub (notification) guidance
178 o section 6.4.2 identifies "subscribing to an information stream of
179 route changes receiving notifications about peers coming up or
180 going down"
182 o section 6.3 notes that when local config preempts I2RS, external
183 notification might be necessary
185 In addition [i2rs-usecase]has relevant requirements. A small subset
186 includes:
188 o L-Data-REQ-12: The I2RS interface should support user
189 subscriptions to data with the following parameters: push of data
190 synchronously or asynchronously via registered subscriptions...
192 o L-DATA-REQ-07: The I2RS interface (protocol and IMs) should allow
193 a subscribe to select portions of the data model.
195 o PI-REQ01: monitor the available routes installed in the RIB of
196 each forwarding device, including near real time notification of
197 route installation and removal.
199 o BGP-REQ10: I2RS client should be able instruct the I2RS agent(s)
200 to notify the I2RS client when the BGP processes on an associated
201 routing system observe a route change to a specific set of IP
202 Prefixes and associated prefixes....The I2RS agent should be able
203 to notify the client via publish or subscribe mechanism.
205 o IGP-REQ-07: The I2RS interface (protocol and IMs) should support a
206 mechanism where the I2RS Clients can subscribe to the I2RS Agent's
207 notification of critical node IGP events.
209 o MPLS-LDP-REQ-03: The I2RS Agent notifications should allow an I2RS
210 client to subscribe to a stream of state changes regarding the LDP
211 sessions or LDP LSPs from the I2RS Agent.
213 o L-Data-REQ-01: I2rs must be able to collect large data set from
214 the network with high frequency and resolution with minimal impact
215 to the device's CPU and memory.
217 And [i2rs-traceability] has Pub/Sub requirements listed in
218 Section 7.4.3.
220 o I2RS Agents should support publishing I2RS trace log information
221 to that feed as described in [i2rs-arch]. Subscribers would then
222 receive a live stream of I2RS interactions in trace log format and
223 could flexibly choose to do a number of things with the log
224 messages
226 2.2. Pub/Sub variants on Network Elements
228 This document is intended to cover requirements beyond I2RS. Looking
229 at history, there are many examples of switching and routing
230 protocols which have done explicit or implicit pub/sub in the past.
231 In addition, new policy notification mechanisms which operate on
232 Switches and Routers are being specified now. A very small subset of
233 these includes:
235 o Routing Adjacencies in MPLS VPNs [RFC6513]
237 o OSPF Route Flooding [RFC2328]
239 o Multicast topology establishment protocols (IGMP, PIM, etc.)
240 o Audio-Video Bridging streams needing guaranteed latency
241 [AVB-latency] (802.1Q-2011 Clause 35)
243 o Secure Automation and Continuous Monitoring (SACM)
244 [sacm-requirements]
246 o "Peer Mount" subscriptions for configuration verification between
247 peers[draft-voit-netmod]
249 Worthy of note in the list above is the wide variety of broadcast,
250 multicast, and unicast transports used. In addition some transports
251 are at L3, and some at L2. Therefore if we are going to attempt a
252 generic Pub/Sub mechanism, it will need to be structured so that it
253 may support alternative transports. Looking at the nearer term based
254 on current I2RS requirements, NETCONF should be our transport
255 starting point as it supports connection oriented/Unicast
256 communication. But we need to be prepared to decouple where viable
257 to support Multicast and Broadcast distribution as well.
259 2.3. Existing Generalized Pub/Sub Implementations
261 TIBCO, RSS, CORBA, and other technologies all show precursor Pub/Sub
262 technologies. However there are new needs described in Section 4
263 below which these technologies do not serve. We need a new pub-sub
264 technology.
266 There are at least two widely deployed generalized pub/sub
267 implementations which come close to current needs: XMPP[XEP-0060] and
268 DDS[OMG-DDS]. Both serve as proof-points that a highly scalable
269 distributed datastore implementation connecting millions of edge
270 devices is possible.
272 Because of these proof points, we can be comfortable that the
273 underlying technologies can enable reusable generalized YANG object
274 distribution. Analysis will need to fully dimension the speed and
275 scale of such object distribution for various subtree sizes and
276 transport types.
278 3. Terminology
280 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
281 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
282 document are to be interpreted as described in [RFC2119].
284 A Subscriber makes requests for set(s) of YANG object data.
286 A Publisher is responsible for distributing subscribed YANG object
287 data per the terms of a Subscription. In general, a Publisher is the
288 owner of the YANG datastore that is subjected to the Subscription.
290 A Receiver is the target where a Publisher pushes updates. In
291 general, the Receiver and Subscriber will be the same entity. A
292 Subscription Service provides Subscriptions to Subscribers of YANG
293 data.
295 A Subscription Service interacts with the Publisher of the YANG data
296 as needed to provide the data per the terms of the Subscription.
298 A Subscription Request for one or more YANG subtrees (including
299 single leafs) made by the Subscriber of a Publisher and targeted to a
300 Receiver. A Subscription may include constraints which dictate how
301 often or under what conditions YANG information updates might be
302 sent.
304 A Subscription is a contract between a Subscription Service and a
305 Subscriber that stipulates the data to be pushed and the associated
306 terms.
308 A YANG datastore is a conceptual datastore that contains hierarchical
309 data defined in YANG data models. It is what is referred in existing
310 RFCs as "NETCONF datastore". However, as the same datastore is no
311 longer tied to NETCONF as a specific transport, the term "YANG
312 datastore" is deemed more appropriate.
314 An Update provides object changes which have occurred within
315 subscribed YANG subtree(s). An Update must include the current
316 status of (data) node instances which according to any filtering are
317 reportably different from the previously provided state. An Update
318 may include a bundled set of ordered/sequential changes for a given
319 object which have been made since the last update.
321 A Filter contains evaluation criteria which are evaluated against
322 YANG object(s) within a Subscription. There are two types of
323 Filters: Subtree Filters which identify selected objects/nodes
324 published under a target data node, and object Property Filters where
325 an object should only be published if it has propert(ies) meeting
326 specified Filter criteria. For "on-change" notifications, passing
327 through the Filter requires that a subscribed object is now different
328 that from the previous Push, AND at least one of the YANG objects
329 being evaluated has changed since the last Update.
331 4. Requirements
333 Many of the requirements within this section have been morphed from
334 OMG's DDS and XMPP.org's requirements specifications.
336 4.1. Assumptions for Subscriber Behavior
338 This document provides requirements for the Subscription Service. It
339 does not define all the requirements for the Subscriber/Receiver.
340 However in order to frame the desired behavior of the Subscription
341 Service, it is important to specify key input constraints.
343 A Subscriber SHOULD avoid attempting to establish multiple
344 Subscriptions pertaining to the same information, i.e. referring to
345 the same datastore YANG subtrees.
347 A Subscriber MAY provide Subscription QoS criteria to the
348 Subscription Service such that if the Subscription Service is unable
349 to meet those criteria, the Subscription SHOULD NOT be established.
351 When a Subscriber needs to restart, the Subscriber MAY have to
352 resubscribe. There is no requirement for the life span of the
353 Subscription to extend beyond the life span of the Subscriber.
355 A Subscriber MUST be able to infer when a Subscription Service is no
356 longer active and when no more updates are being sent.
358 A Subscriber MAY check with a Subscription Service to validate the
359 existence and monitored subtrees of a Subscription.
361 A Subscriber MUST be able to periodically lease and re-lease a
362 Subscription from a Subscription Service.
364 4.2. Subscription Service Requirements
366 4.2.1. General
368 A Subscription Service MUST support the ability to create, renew,
369 timeout, and terminate a Subscription.
371 A Subscription Service MUST be able to support and independently
372 track one or more Subscription Requests by the same Subscriber.
374 A Subscription Service MUST be able to support an add/change/delete
375 of one or more YANG subtrees as part of the same Subscription
376 Request.
378 A Subscription Service MUST support Subscriptions against operational
379 datastores, configuration datastores, or both.
381 A Subscription Service MUST be able support a Subtree Filter so that
382 subscribed updates under a target node might publish only operational
383 data, only configuration data, or both.
385 A Subscription MAY include filters as defined within a Subscription
386 Request, Therefore the Subscription Service MUST publish only data
387 nodes that meet the filter criteria within a Subscription.
389 A Subscription Service MUST support the ability to subscribe to
390 periodic updates. The subscription period MUST be configurable as
391 part of the subscription request.
393 A Subscription Service SHOULD support the ability to subscribe to
394 updates "on-change", i.e. whenever values of subscribed data objects
395 change.
397 For "on-change" updates, the Subscription Service MUST support a
398 dampening period that needs to pass before the first or subsequent
399 "on-change" updates are sent. The dampening period SHOULD be
400 configurable as part of the subscription request.
402 A Subscription Service MUST allow Subscriptions to be monitored.
403 Specifically, a Subscription Service MUST at a minimum maintain
404 information about which Subscriptions are being serviced, the terms
405 of those subscriptions (e.g. what data is being subscribed,
406 associated filters, update policy - on change, periodic), and the
407 overall status of the Subscription - e.g. active or suspended.
409 A Subscription Service SHOULD be able to interpret Subscription QoS
410 parameters, and only establish a Subscription if it is possible to
411 meet the QoS needs of the provided QoS parameters.
413 A Subscription Service MUST support terminating of a Subscription
414 when requested by the Subscriber.
416 A Subscription Service SHOULD support the ability to suspend and to
417 resume a Subscription on request of a client.
419 A Subscription Service MAY at its discretion revoke or suspend an
420 existing subscription. Reasons may include transitory resource
421 limitation, credential expiry, failure to reconfirm a subscription,
422 loss of connectivity with the Receiver, operator CLI, and/or others.
423 When this occurs, the Subscription Service MUST notify the Subscriber
424 and update subscription status.
426 A Subscription Service MAY offer the ability to modify a subscription
427 filter. If such an ability is offered, the service MUST provide
428 subscribers with an indication at what point the modified
429 subscription goes into effect.
431 4.2.2. Negotiation
433 A Subscription Service MUST be able to negotiate the following terms
434 of a Subscription:
436 o The policy: i.e. whether updates are on-change of periodic
438 o The interval, for periodic publication policy
440 o The dampening period, for on-change update policy
442 o Any filters associated with a subtree subscription
444 A Subscription Service SHOULD be able to negotiate QoS criteria for a
445 Subscription. Examples of Subscription QoS criteria may include
446 reliability of the Subscription Service, reaction time between a
447 monitored YANG subtree/object change and a corresponding notification
448 push, and the Subscription Service's ability to support certain
449 levels of object liveliness.
451 In cases where a Subscription Request cannot be fulfilled, the
452 Subscription Service MUST include in its decline a set of criteria
453 that would have been acceptable when the Subscription Request was
454 made. For example, if periodic updates were requested with too short
455 update intervals for the specified data set, the minimum acceptable
456 interval period SHOULD be included. If on-change updates were
457 requested with a dampening period, the minimum acceptable dampening
458 period SHOULD be included, or an indication whether only periodic
459 updates are supported along with the minimum acceptable interval
460 period for the data set being subscribed to.
462 4.2.3. Update Distribution
464 For "on-change" updates, the Subscription Service MUST only send
465 deltas to the object data for which a change occurred. [Otherwise
466 the subscriber will not know what has actually undergone change.]
467 The updates for each object MUST include an indication whether it was
468 removed, added, or changed.
470 When a Subscription Service is not able to send updates per its
471 subscription contract, the Subscription MUST notify subscribers and
472 put the subscription into a state of indicating the Subscription was
473 suspended by the service. When able to resume service, subscribers
474 need to be notified as well. If unable to resume service, the
475 Subscription Service MAY terminate the subscription and notify
476 Subscribers accordingly.
478 When a Subscription with "on-change" updates is suspended and then
479 resumed, the first update SHOULD include updates of any changes that
480 occurred while the Subscription was suspended, with the current
481 value. The Subscription Service MUST provide a clear indication when
482 this capability is not supported (because in this case a client
483 application may have to synchronize state separately).
485 Multiple objects being pushed to a Subscriber, perhaps from different
486 Subscriptions, SHOULD be bundled together into a single Update.
488 The sending of an Update MUST NOT be delayed beyond the Push Latency
489 of any enclosed object changes.
491 The sending of an Update MUST NOT be delayed beyond the dampening
492 period of any enclosed object changes.
494 The sending of an Update MUST NOT occur before the dampening period
495 expires for any enclosed object changes.
497 A Subscription Service MAY, as an option, support a persistence/
498 replay capability.
500 4.2.4. Transport
502 A Subscription Service SHOULD support different transports.
504 A Subscription Service SHOULD support different encodings of payload.
506 It MUST be possible for Receivers to associate the update with a
507 specific Subscription.
509 In the case of connection-oriented transport, when a transport
510 connection drops, the associated Subscription SHOULD be terminated.
511 It is up the Subscriber to request a new Subscription.
513 4.2.5. Security Requirements
515 As part of the Subscription establishment, there MUST be mutual
516 authentication between the Subscriber and the Subscription Service.
518 When there are multiple Subscribers, it SHOULD be possible to provide
519 cryptographic authentication in such a way that no Subscriber can
520 pose as the original Subscription Service.
522 Versioning MUST be supported.
524 A Subscription could be used to attempt to retrieve information that
525 a client has not authorized access to. Therefore it is important
526 that data pushed based on Subscriptions is authorized in the same way
527 that regular data retrieval operations are authorized. Data being
528 pushed to a client MUST be filtered accordingly, just like if the
529 data were being retrieved on-demand. For Unicast transports, the
530 NETCONF Authorization Control Model applies.
532 Additions or changes within a subscribed subtree structure MUST be
533 validated against authorization methods before Subscription Updates
534 including new subtree information are pushed.
536 A loss of authenticated access to subtree or node SHOULD be
537 communicated to the Subscriber.
539 Subscription requests, including requests to create, terminate,
540 suspend, and resume Subscriptions MUST be properly authorized.
542 When the Subscriber and Receiver are different, the Receiver MUST be
543 able to terminate any Subscription to it where objects are being
544 delivered over a Unicast transport.
546 A Subscription Service SHOULD decline a Subscription Request if it
547 would deplete its resources. It is preferable to decline a
548 Subscription when originally requested, rather than having to
549 terminate it prematurely later.
551 4.2.6. Subscription QoS
553 A Subscription Service SHOULD be able to negotiate the following
554 Subscription QoS parameters with a Subscriber: Dampening,
555 Reliability, Deadline, and Bundling.
557 4.2.6.1. Liveliness
559 A Subscription Service MUST be able to respond to requests to verify
560 the Liveliness of a subscription.
562 A Subscription Service MUST be able to report the currently monitored
563 Nodes of a Subscription.
565 4.2.6.2. Dampening
567 A Subscription Service MUST be able to negotiate the minimum time
568 separation since the previous update before transmitting a subsequent
569 update for Subscription. (Note: this is intended to confine the
570 visibility of volatility into something digestible by the receiver.)
572 4.2.6.3. Reliability
574 A Subscription Service MAY send Updates over Best Effort and Reliable
575 transports.
577 4.2.6.4. Coherence
579 For a particular Subscription, every update to a subscribed object
580 MUST be sent to the Receiver in sequential order.
582 4.2.6.5. Presentation
584 The Subscription Service SHOULD have the ability to bundle a set of
585 discrete object notifications into a single publishable update for a
586 Subscription. A bundle MAY include information on different Data
587 Nodes and/or multiple updates about a single Data Node.
589 For any bundled updates, the Subscription Service MUST provide
590 information for a Receiver to reconstruct the order and timing of
591 updates.
593 4.2.6.6. Deadline
595 The Subscription Service MUST be able to push updates at a regular
596 cadence that corresponds with Subscriber specified start and end
597 timestamps. (Note: the regular cadence can drive one, a discrete
598 quantity, or an unbounded set of periodic updates.)
600 4.2.6.7. Push Latency
602 The Subscription Service SHOULD be able to delay Updates on object
603 push for a configurable period per Subscriber.
605 It MUST be possible for an administrative entity to determine the
606 Push latency between object change in a monitored subtree and the
607 Subscription Service Push of the update transmission.
609 4.2.7. Filtering
611 If no filtering criteria are provided, or if filtering criteria are
612 met, updates for a subscribed object MUST be pushed, subject to the
613 QoS limits established for the subscription.
615 It MUST be possible for the Subscription Service to receive Filter(s)
616 from a Subscriber and apply them to corresponding object(s) within a
617 Subscription.
619 It MUST be possible to attach one or more Subtree and/or Property
620 Filters to a subscription. Mandatory Property Filter types include:
622 o For character based object properties, filter values which are
623 exactly equal to a provided string, not equal to the string, or
624 containing a string.
626 o For numeric based object properties, filter values which are =,
627 !=, <, <=, >, >= a provided number.
629 It SHOULD be possible for Property Filtering criteria to evaluate
630 more than one property of a particular subscribed object as well as
631 apply multiple filters against a single property.
633 It SHOULD be possible to establish query match criteria on additional
634 objects to be used in conjunction with Property Filtering criteria on
635 a subscribed object. (For example: if A has changed AND B=1, then
636 Push A.) (Note: Query match capability may be done on objects within
637 the datastore even if those objects are not included within the
638 subscription. This of course assumes the subscriber has read access
639 to those objects.)
641 4.2.8. Assurance and Monitoring
643 It MUST be possible to fetch the state of a single subscription from
644 a Subscription Service.
646 It MUST be possible to fetch the state of all subscriptions of a
647 particular Subscriber.
649 It MUST be possible to fetch a list and status of all Subscription
650 Requests over a period of time. If there us a failure, some failure
651 reasons MAY include:
653 o Improper security credentials provided to access the target node;
655 o Target node referenced does not exist;
657 o Subscription type requested is not available upon the target node;
659 o Out of resources, or resources not available;
661 o Incomplete negotiations with the Subscriber.
663 5. Security Considerations
665 There are no additional security considerations beyond the
666 requirements listed in Section 4.2.5.
668 6. IANA Considerations
670 This document has no actions for IANA.
672 7. Acknowledgements
674 We wish to acknowledge the helpful contributions, comments, and
675 suggestions that were received from Ambika Tripathy and Prabhakara
676 Yellai as well as the helpfulness of related end-to-end system
677 context info from Nancy Cam Winget, Ken Beck, and David McGrew.
679 8. References
681 8.1. Normative References
683 [i2rs-arch]
684 Atlas, A., "An Architecture for the Interface to the
685 Routing System", December 2015,
686 .
689 [i2rs-traceability]
690 Clarke, J., Salgueiro, G., and C. Pignataro, "Interface to
691 the Routing System (I2RS) Traceability: Framework and
692 Information Model", December 2015,
693 .
696 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
697 Requirement Levels", BCP 14, RFC 2119,
698 DOI 10.17487/RFC2119, March 1997,
699 .
701 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328,
702 DOI 10.17487/RFC2328, April 1998,
703 .
705 [RFC5277] Chisholm, S. and H. Trevino, "NETCONF Event
706 Notifications", RFC 5277, DOI 10.17487/RFC5277, July 2008,
707 .
709 [RFC6470] Bierman, A., "Network Configuration Protocol (NETCONF)
710 Base Notifications", RFC 6470, DOI 10.17487/RFC6470,
711 February 2012, .
713 [RFC6513] Rosen, E., Ed. and R. Aggarwal, Ed., "Multicast in MPLS/
714 BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513, February
715 2012, .
717 8.2. Informative References
719 [AVB-latency]
720 Jeffree, T., "802.1Qav - Forwarding and Queuing
721 Enhancements for Time-Sensitive Streams", December 2009,
722 .
724 [datastore-push]
725 Clemm, A., Gonzalez Prieto, A., and E. Voit, "Subscribing
726 to datastore push updates", October 2015,
727 .
730 [draft-voit-netmod]
731 Voit, E., "Requirements for Peer Mounting of YANG subtrees
732 from Remote Datastores", September 2015,
733 .
736 [i2rs-usecase]
737 Hares, S. and M. Chen, "Summary of I2RS Use Case
738 Requirements", November 2015,
739 .
742 [OMG-DDS] "Data Distribution Service for Real-time Systems, version
743 1.2", January 2007, .
745 [sacm-requirements]
746 Cam Winget, N., "Secure Automation and Continuous
747 Monitoring (SACM) Requirements", July 2015,
748 .
751 [XEP-0060]
752 Millard, P., "XEP-0060: Publish-Subscribe", July 2010,
753 .
755 Authors' Addresses
757 Eric Voit
758 Cisco Systems
760 Email: evoit@cisco.com
762 Alexander Clemm
763 Cisco Systems
765 Email: alex@cisco.com
767 Alberto Gonzalez Prieto
768 Cisco Systems
770 Email: albertgo@cisco.com