idnits 2.17.1
draft-ietf-i2rs-pub-sub-requirements-09.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 (May 17, 2016) is 2863 days in the past. Is this
intentional?
Checking references for intended status: Informational
----------------------------------------------------------------------------
** Obsolete normative reference: RFC 5539 (Obsoleted by RFC 7589)
Summary: 1 error (**), 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: Informational A. Gonzalez Prieto
5 Expires: November 18, 2016 Cisco Systems
6 May 17, 2016
8 Requirements for Subscription to YANG Datastores
9 draft-ietf-i2rs-pub-sub-requirements-09
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 November 18, 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 . . . . . . . . . . . . . . . . . . . . . 3
62 2.2. Pub/Sub Variants on Network Elements . . . . . . . . . . 5
63 2.3. Existing Generalized Pub/Sub Implementations . . . . . . 5
64 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
65 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 7
66 4.1. Assumptions for Subscriber Behavior . . . . . . . . . . . 7
67 4.2. Subscription Service Requirements . . . . . . . . . . . . 7
68 4.2.1. General . . . . . . . . . . . . . . . . . . . . . . . 7
69 4.2.2. Negotiation . . . . . . . . . . . . . . . . . . . . . 9
70 4.2.3. Update Distribution . . . . . . . . . . . . . . . . . 9
71 4.2.4. Transport . . . . . . . . . . . . . . . . . . . . . . 10
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. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15
79 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
80 8.1. Normative References . . . . . . . . . . . . . . . . . . 15
81 8.2. Informative References . . . . . . . . . . . . . . . . . 16
82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
84 1. Introduction
86 Applications interacting with YANG datastores require capabilities
87 beyond the traditional client-server configuration of network
88 elements. One class of such applications are service-assurance
89 applications which must maintain a continuous view of operational
90 data and state. Another class of applications are security
91 applications which must continuously track changes made upon network
92 elements to ensure compliance to corporate policy.
94 Periodic fetching of data is not an adequate solution for
95 applications requiring frequent or prompt updates of remote object
96 state. Applying polling-based solutions here imposes load on
97 networks, devices, and applications. Additionally, polling solutions
98 are brittle in the face of communication glitches, and have
99 limitations in their ability to synchronize and calibrate retrieval
100 intervals across a network. These limitations can be addressed by
101 including generic object subscription mechanisms within Network
102 Elements, and allowing these mechanisms to be applied in the context
103 of data that is conceptually contained in YANG datastores.
105 This document aggregates requirements for such subscription from a
106 variety of deployment scenarios.
108 2. Business Drivers
110 For decades, information delivery of current network state has been
111 accomplished either by fetching from operations interfaces, or via
112 dedicated, customized networking protocols. With the growth of
113 centralized orchestration infrastructures, imperative policy
114 distribution, and YANG's ascent as the dominant data modeling
115 language for use in programmatic interfaces to network elements, this
116 mixture of fetch plus custom networking protocols is no longer
117 sufficient. What is needed is a push mechanism that is able to
118 deliver object changes as they happen.
120 These push distribution mechanisms will not replace existing
121 networking protocols. Instead they will supplement these protocols,
122 providing different response time, peering, scale, and security
123 characteristics.
125 Push solutions will not displace all existing operations
126 infrastructure needs. And SNMP and MIBs will remain widely deployed
127 and the defacto choice for many monitoring solutions. But some
128 functions could be displaced. Arguably the biggest shortcoming of
129 SNMP for those applications concerns the need to rely on periodic
130 polling, because it introduces additional load on the network and
131 devices, because it is brittle in case polling cycles are missed, and
132 because is hard to synchronize and calibrate across a network. If
133 applications can only use polling type interaction patterns with YANG
134 datastores, similar issues can be expected.
136 2.1. Pub/Sub in I2RS
138 Various I2RS documents highlight the need to provide Pub/Sub
139 capabilities between network elements. From [i2rs-arch], there are
140 references throughout the document beginning in section 6.2. Some
141 specific examples include:
143 o section 7.6 provides high level pub/sub (notification) guidance
144 o section 6.4.2 identifies "subscribing to an information stream of
145 route changes receiving notifications about peers coming up or
146 going down"
148 o section 6.3 notes that when local config preempts I2RS, external
149 notification might be necessary
151 In addition [i2rs-usecase] has relevant requirements. A small subset
152 includes:
154 o L-Data-REQ-12: The I2RS interface should support user
155 subscriptions to data with the following parameters: push of data
156 synchronously or asynchronously via registered subscriptions...
158 o L-DATA-REQ-07: The I2RS interface (protocol and IMs) should allow
159 a subscriber to select portions of the data model.
161 o PI-REQ01: monitor the available routes installed in the RIB of
162 each forwarding device, including near real time notification of
163 route installation and removal.
165 o BGP-REQ10: I2RS client should be able to instruct the I2RS
166 agent(s) to notify the I2RS client when the BGP processes on an
167 associated routing system observe a route change to a specific set
168 of IP Prefixes and associated prefixes....The I2RS agent should be
169 able to notify the client via publish or subscribe mechanism.
171 o IGP-REQ-07: The I2RS interface (protocol and IMs) should support a
172 mechanism where the I2RS Clients can subscribe to the I2RS Agent's
173 notification of critical node IGP events.
175 o MPLS-LDP-REQ-03: The I2RS Agent notifications should allow an I2RS
176 client to subscribe to a stream of state changes regarding the LDP
177 sessions or LDP LSPs from the I2RS Agent.
179 o L-Data-REQ-01: I2rs must be able to collect large data set from
180 the network with high frequency and resolution with minimal impact
181 to the device's CPU and memory.
183 And [i2rs-traceability] has Pub/Sub requirements listed in
184 Section 7.4.3.
186 o I2RS Agents should support publishing I2RS trace log information
187 to that feed as described in [i2rs-arch]. Subscribers would then
188 receive a live stream of I2RS interactions in trace log format and
189 could flexibly choose to do a number of things with the log
190 messages
192 2.2. Pub/Sub Variants on Network Elements
194 This document is intended to cover requirements beyond I2RS. Looking
195 at history, there are many examples of switching and routing
196 protocols which have done explicit or implicit pub/sub in the past.
197 In addition, new policy notification mechanisms which operate on
198 switches and routers are being specified now. A small subset of
199 current and past subscription mechanisms includes:
201 o Multicast topology establishment is accomplished before any
202 content delivery is made to endpoints (IGMP, PIM, etc.)
204 o Secure Automation and Continuous Monitoring (SACM) allows
205 subscription into devices which then may push spontaneous changes
206 in their configured hardware and software[sacm-requirements]
208 o In MPLS VPNs [RFC6513] a Customer Edge router exchanges PIM
209 control messages before PE Routing Adjacencies are passed.
210 [RFC6513]
212 o After OSPF establishes its adjacencies, Link State Advertisement
213 will then commence [RFC2328]
215 Worthy of note in the examples above is the wide variety of
216 underlying transports. A generalized Pub/Sub mechanism therefore
217 should be structured to support alternative transports. Based on
218 current I2RS requirements, NETCONF should be the initially supported
219 transport based on the need for connection-oriented/unicast
220 communication. Eventual support for multicast and broadcast
221 subscription update distribution will be needed as well.
223 2.3. Existing Generalized Pub/Sub Implementations
225 TIBCO, RSS, CORBA, and other technologies all show precursor Pub/Sub
226 technologies. However there are new needs described in Section 4
227 below which these technologies do not serve. We need a new pub-sub
228 technology.
230 There are at least two widely deployed generalized pub/sub
231 implementations which come close to current needs: XMPP[XEP-0060] and
232 DDS[OMG-DDS]. Both serve as proof-points that a highly scalable
233 distributed datastore implementation connecting millions of edge
234 devices is possible.
236 Because of these proof points, we can be comfortable that the
237 underlying technologies can enable reusable generalized YANG object
238 distribution. Analysis will need to fully dimension the speed and
239 scale of such object distribution for various subtree sizes and
240 transport types.
242 3. Terminology
244 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
245 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
246 document are to be interpreted as described in [RFC2119]. Although
247 this document is not a protocol specification, the use of this
248 language clarifies the instructions to protocol designers producing
249 solutions that satisfy the requirements set out in this document.
251 A Subscriber makes requests for set(s) of YANG object data.
253 A Publisher is responsible for distributing subscribed YANG object
254 data per the terms of a Subscription. In general, a Publisher is the
255 owner of the YANG datastore that is subjected to the Subscription.
257 A Receiver is the target to which a Publisher pushes updates. In
258 general, the Receiver and Subscriber will be the same entity. A
259 Subscription Service provides Subscriptions to Subscribers of YANG
260 data.
262 A Subscription Service interacts with the Publisher of the YANG data
263 as needed to provide the data per the terms of the Subscription.
265 A Subscription Request for one or more YANG subtrees (including
266 single leafs) is made by the Subscriber of a Publisher and is
267 targeted to a Receiver. A Subscription may include constraints which
268 dictate how often or under what conditions YANG information updates
269 might be sent.
271 A Subscription is a contract between a Subscription Service and a
272 Subscriber that stipulates the data to be pushed and the associated
273 terms.
275 A datastore is defined in [RFC6241].
277 An Update provides object changes which have occurred within
278 subscribed YANG subtree(s). An Update must include the current
279 status of (data) node instances which according to any filtering are
280 reportably different from the previously provided state. An Update
281 may include a bundled set of ordered/sequential changes for a given
282 object that have been made since the last update.
284 A Filter contains evaluation criteria which are evaluated against
285 YANG object(s) within a Subscription. There are two types of
286 Filters: Subtree Filters which identify selected objects/nodes
287 published under a target data node, and object element and attribute
288 Filters where an object should only be published if it has properties
289 meeting specified Filter criteria.
291 4. Requirements
293 Many of the requirements within this section have been adapted from
294 XMPP[XEP-0060] and DDS[OMG-DDS] requirements specifications.
296 4.1. Assumptions for Subscriber Behavior
298 This document provides requirements for the Subscription Service. It
299 does not define all the requirements for the Subscriber/Receiver.
300 However in order to frame the desired behavior of the Subscription
301 Service, it is important to specify key input constraints.
303 A Subscriber SHOULD avoid attempting to establish multiple
304 Subscriptions pertaining to the same information, i.e., referring to
305 the same datastore YANG subtrees.
307 A Subscriber MAY provide Subscription QoS criteria to the
308 Subscription Service; if the Subscription Service is unable to meet
309 those criteria, the Subscription SHOULD NOT be established.
311 When a Subscriber and Receiver are the same entity and the transport
312 session is lost/terminated, the Subscriber MUST reestablish any
313 subscriptions it previously created via signalling over the transport
314 session. I.e., There is no requirement for the life span of such
315 signaled Subscriptions extend beyond the life span of the transport
316 session.
318 A Subscriber MUST be able to infer when a Subscription Service is no
319 longer active and when no more updates are being sent.
321 A Subscriber MAY check with a Subscription Service to validate the
322 existence and monitored subtrees of a Subscription.
324 A Subscriber MUST be able to periodically lease and extend the lease
325 of a Subscription from a Subscription Service.
327 4.2. Subscription Service Requirements
329 4.2.1. General
331 A Subscription Service MUST support the ability to create, renew,
332 timeout, and terminate a Subscription.
334 A Subscription Service MUST be able to support and independently
335 track multiple Subscription Requests by the same Subscriber.
337 A Subscription Service MUST be able to support an add/change/delete
338 of subscriptions to multiple YANG subtrees as part of the same
339 Subscription Request.
341 A Subscription Service MUST support Subscriptions against operational
342 datastores, configuration datastores, or both.
344 A Subscription Service MUST be able support filtering so that
345 subscribed updates under a target node might publish only operational
346 data, only configuration data, or both.
348 A Subscription MAY include Filters as defined within a Subscription
349 Request, therefore the Subscription Service MUST publish only data
350 nodes that meet the Filter criteria within a Subscription.
352 A Subscription Service MUST support the ability to subscribe to
353 periodic updates. The subscription period MUST be configurable as
354 part of the subscription request.
356 A Subscription Service SHOULD support the ability to subscribe to
357 updates "on-change", i.e., whenever values of subscribed data objects
358 change.
360 For "on-change" updates, the Subscription Service MUST support a
361 dampening period that needs to pass before the first or subsequent
362 "on-change" updates are sent. The dampening period SHOULD be
363 configurable as part of the subscription request.
365 A Subscription Service MUST allow Subscriptions to be monitored.
366 Specifically, a Subscription Service MUST at a minimum maintain
367 information about which Subscriptions are being serviced, the terms
368 of those subscriptions (e.g., what data is being subscribed,
369 associated Filters, update policy - on change, periodic), and the
370 overall status of the Subscription - e.g., active or suspended.
372 A Subscription Service MUST support terminating of a Subscription
373 when requested by the Subscriber.
375 A Subscription Service SHOULD support the ability to suspend and to
376 resume a Subscription on request of a client.
378 A Subscription Service MAY at its discretion revoke or suspend an
379 existing subscription. Reasons may include transitory resource
380 limitation, credential expiry, failure to reconfirm a subscription,
381 loss of connectivity with the Receiver, operator CLI, and/or others.
383 When this occurs, the Subscription Service MUST notify the Subscriber
384 and update subscription status.
386 A Subscription Service MAY offer the ability to modify a subscription
387 Filter. If such an ability is offered, the service MUST provide
388 subscribers with an indication telling at what point the modified
389 subscription goes into effect.
391 4.2.2. Negotiation
393 A Subscription Service MUST be able to negotiate the following terms
394 of a Subscription:
396 o The policy: i.e., whether updates are on-change or periodic
398 o The interval, for periodic publication policy
400 o The on-change policy dampening period (if the on-change policy is
401 supported)
403 o Any Filters associated with a subtree subscription
405 A Subscription Service SHOULD be able to negotiate QoS criteria for a
406 Subscription. Examples of Subscription QoS criteria may include
407 reliability of the Subscription Service, reaction time between a
408 monitored YANG subtree/object change and a corresponding notification
409 push, and the Subscription Service's ability to support certain
410 levels of object liveliness.
412 In cases where a Subscription Request cannot be fulfilled due to
413 insufficient platform resources, the Subscription Service SHOULD
414 include within its decline hints on criteria that would have been
415 acceptable when the Subscription Request was made. For example, if
416 periodic updates were requested with too short update intervals for
417 the specified data set, an alternative acceptable interval period
418 might be returned from the Publisher. If on-change updates were
419 requested with too-aggressive a dampening period, then an acceptable
420 dampening period may be returned, or alternatively an indication that
421 only periodic updates are supported for the requested object(s).
423 4.2.3. Update Distribution
425 For "on-change" updates, the Subscription Service MUST only send
426 deltas to the object data for which a change occurred. [Otherwise
427 the subscriber might not know what has actually undergone change.]
428 The updates for each object MUST include an indication whether it was
429 removed, added, or changed.
431 When a Subscription Service is not able to send updates per its
432 subscription contract, the Subscription MUST notify subscribers and
433 put the subscription into a state indicating the Subscription was
434 suspended by the service. When able to resume service, subscribers
435 need to be notified as well. If unable to resume service, the
436 Subscription Service MAY terminate the subscription and notify
437 Subscribers accordingly.
439 When a Subscription with "on-change" updates is suspended and then
440 resumed, the first update SHOULD include updates of any changes that
441 occurred while the Subscription was suspended, with the current
442 value. The Subscription Service MUST provide a clear indication when
443 this capability is not supported (because in this case a client
444 application may have to synchronize state separately).
446 Multiple objects being pushed to a Subscriber, perhaps from different
447 Subscriptions, SHOULD be bundled together into a single Update.
449 The sending of an Update MUST NOT be delayed beyond the Push Latency
450 of any enclosed object changes.
452 The sending of an Update MUST NOT be delayed beyond the dampening
453 period of any enclosed object changes.
455 The sending of an Update MUST NOT occur before the dampening period
456 expires for any enclosed object changes.
458 A Subscription Service MAY, as an option, support a replay capability
459 so that a set of updates generated during a previous time internal
460 can be sent to a Receiver.
462 4.2.4. Transport
464 It is possible for updates coming from a Subscription Service to be
465 pushed over different types of transports such as NETCONF, RESTCONF,
466 and HTTP. Beyond existing transports, this Subsription Service will
467 applicable for emerging protocols such as those being defined in
468 [i2rs-usecase]. The need for such transport flexibility drives the
469 following requirements.
471 A Subscription Service SHOULD support different transports.
473 A Subscription Service SHOULD support different encodings of payload.
475 It MUST be possible for Receivers to associate the update with a
476 specific Subscription.
478 In the case of connection-oriented transport, when a transport
479 connection drops, the associated Subscription SHOULD be terminated.
480 It is up the Subscriber to request a new Subscription.
482 4.2.5. Security Requirements
484 Some uses of this Subscription Service will push privacy-sensitive
485 updates and metadata. For privacy-sensitive deployments,
486 subscription information MUST be bound within secure, encrypted
487 transport layer mechanisms. For example if NETCONF is used as
488 transport, then [RFC5539] would be a valid option to secure the
489 transported information. The Subscription Service can also be used
490 with emerging privacy-sensitive deployment contexts as well. As an
491 example, deployments based on [i2rs-usecase] would apply these
492 requirements in conjunction with those documented within
493 [i2rs-environment-security] and [i2rs-protocol-security] to secure
494 ephemeral state information being pushed from a Network Element.
496 As part of the Subscription establishment, mutual authentication MUST
497 be used between the Subscriber and the Subscription Service.
499 Subscribers MUST NOT be able to pose as the original Subscription
500 Service.
502 Versioning of any subscription protocols MUST be supported so that
503 the capabilities and behaviors expected of specific technology
504 implementations can be exposed.
506 A Subscription could be used to attempt to retrieve information to
507 which a client has no authorized access. Therefore it is important
508 that data pushed based on Subscriptions is authorized in the same way
509 that regular data retrieval operations are authorized. Data being
510 pushed to a client MUST be filtered accordingly, just like if the
511 data were being retrieved on-demand. For Unicast transports, the
512 NETCONF Authorization Control Model applies.
514 Additions or changes within a subscribed subtree structure MUST be
515 validated against authorization methods before Subscription Updates
516 including new subtree information are pushed.
518 A loss of authenticated access to target subtree or node SHOULD be
519 communicated to the Subscriber.
521 For any encrypted information exchanges, commensurate strength
522 security mechanisms MUST be available and SHOULD be used. This
523 includes all stages of the Subscription and update push process.
525 Subscription requests, including requests to create, terminate,
526 suspend, and resume Subscriptions MUST be properly authorized.
528 When the Subscriber and Receiver are different, the Receiver MUST be
529 able to terminate any Subscription to it where objects are being
530 delivered over a Unicast transport.
532 A Subscription Service SHOULD decline a Subscription Request if it is
533 likely to deplete its resources. It is preferable to decline a
534 Subscription when originally requested, rather than having to
535 terminate it prematurely later.
537 When the Subscriber and Receiver are different, and when the
538 underlying transport connection passes credentials as part of
539 transport establishment, then potentially pushed objects MUST be
540 excluded from a push update if that object doesn't have read access
541 visibility for that the Receiver.
543 4.2.6. Subscription QoS
545 A Subscription Service SHOULD be able to negotiate the following
546 Subscription QoS parameters with a Subscriber: Dampening,
547 Reliability, Deadline, and Bundling.
549 A Subscription Service SHOULD be able to interpret Subscription QoS
550 parameters, and only establish a Subscription if it is possible to
551 meet the QoS needs of the provided QoS parameters.
553 4.2.6.1. Liveliness
555 A Subscription Service MUST be able to respond to requests to verify
556 the Liveliness of a subscription.
558 A Subscription Service MUST be able to report the currently monitored
559 Nodes of a Subscription.
561 4.2.6.2. Dampening
563 A Subscription Service MUST be able to negotiate the minimum time
564 separation since the previous update before transmitting a subsequent
565 update for Subscription. (Note: this is intended to confine the
566 visibility of volatility into something digestible by the receiver.)
568 4.2.6.3. Reliability
570 A Subscription Service MAY send Updates over Best Effort and Reliable
571 transports.
573 4.2.6.4. Coherence
575 For a particular Subscription, every update to a subscribed object
576 MUST be sent to the Receiver in sequential order.
578 4.2.6.5. Presentation
580 The Subscription Service MAY have the ability to bundle a set of
581 discrete object notifications into a single publishable update for a
582 Subscription. A bundle MAY include information on different Data
583 Nodes and/or multiple updates about a single Data Node.
585 For any bundled updates, the Subscription Service MUST provide
586 information for a Receiver to reconstruct the order and timing of
587 updates.
589 4.2.6.6. Deadline
591 The Subscription Service MUST be able to push updates at a regular
592 cadence that corresponds with Subscriber specified start and end
593 timestamps. (Note: the regular cadence can drive one, a discrete
594 quantity, or an unbounded set of periodic updates.)
596 4.2.6.7. Push Latency
598 The Subscription Service SHOULD be able to delay Updates on object
599 push for a configurable period per Subscriber.
601 It MUST be possible for an administrative entity to determine the
602 Push latency between object change in a monitored subtree and the
603 Subscription Service Push of the update transmission.
605 4.2.6.8. Relative Priority
607 The Subscription Service SHOULD support the relative prioritization
608 of Subscriptions so that dequeuing and discarding of push updates can
609 consider this if there is insufficient bandwidth between Publisher
610 and Receiver.
612 4.2.7. Filtering
614 If no filtering criteria are provided, or if filtering criteria are
615 met, updates for a subscribed object MUST be pushed, subject to the
616 QoS limits established for the subscription.
618 It MUST be possible for the Subscription Service to receive Filter(s)
619 from a Subscriber and apply them to corresponding object(s) within a
620 Subscription.
622 It MUST be possible to attach one or more Subtree and/or object
623 element and attribute Filters to a subscription. Mandatory Filter
624 types include:
626 o For character-based object properties, Filter values which are
627 exactly equal to a provided string, not equal to the string, or
628 containing a string.
630 o For numeric based object properties, Filter values which are =,
631 !=, <, <=, >, >= a provided number.
633 It SHOULD be possible for Filtering criteria to evaluate more than
634 one property of a particular subscribed object as well as apply
635 multiple Filters against a single object.
637 It SHOULD be possible to establish query match criteria on additional
638 objects to be used in conjunction with Filtering criteria on a
639 subscribed object. (For example: if A has changed and B=1, then Push
640 A.) Query match capability may be done on objects within the
641 datastore even if those objects are not included within the
642 subscription. This of course assumes the subscriber has read access
643 to those objects.
645 For on-change subscription updates, an object MUST pass a Filter
646 through a Filter if it has changed since the previous update. This
647 includes if the object has changed multiple times since the last
648 update, and ithe value happens to be the exact same value as the last
649 one sent.
651 4.2.8. Assurance and Monitoring
653 It MUST be possible to fetch the state of a single subscription from
654 a Subscription Service.
656 It MUST be possible to fetch the state of all subscriptions of a
657 particular Subscriber.
659 It MUST be possible to fetch a list and status of all Subscription
660 Requests over a period of time. If there is a failure, some failure
661 reasons might include:
663 o Improper security credentials provided to access the target node;
665 o Target node referenced does not exist;
667 o Subscription type requested is not available upon the target node;
669 o Out of resources, or resources not available;
670 o Incomplete negotiations with the Subscriber.
672 5. Security Considerations
674 There are no additional security considerations beyond the
675 requirements listed in Section 4.2.5.
677 6. IANA Considerations
679 This document has no actions for IANA.
681 7. Acknowledgments
683 We wish to acknowledge the helpful contributions, comments, and
684 suggestions that were received from Ambika Tripathy and Prabhakara
685 Yellai as well as the helpfulness of related end-to-end system
686 context info from Nancy Cam Winget, Ken Beck, and David McGrew.
688 8. References
690 8.1. Normative References
692 [i2rs-arch]
693 Atlas, A., "An Architecture for the Interface to the
694 Routing System", February 2016,
695 .
698 [i2rs-traceability]
699 Clarke, J., Salgueiro, G., and C. Pignataro, "Interface to
700 the Routing System (I2RS) Traceability: Framework and
701 Information Model", February 2016,
702 .
705 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
706 Requirement Levels", BCP 14, RFC 2119,
707 DOI 10.17487/RFC2119, March 1997,
708 .
710 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328,
711 DOI 10.17487/RFC2328, April 1998,
712 .
714 [RFC5539] Badra, M., "NETCONF over Transport Layer Security (TLS)",
715 RFC 5539, DOI 10.17487/RFC5539, May 2009,
716 .
718 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
719 and A. Bierman, Ed., "Network Configuration Protocol
720 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
721 .
723 [RFC6513] Rosen, E., Ed. and R. Aggarwal, Ed., "Multicast in MPLS/
724 BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513, February
725 2012, .
727 8.2. Informative References
729 [i2rs-environment-security]
730 Migault, D., Halpern, J., and S. Hares, "I2RS Environment
731 Security Requirements", April 2016,
732 .
735 [i2rs-protocol-security]
736 Hares, S., Migault, D., and J. Halpern, "I2RS Security
737 Related Requirements", May 2016,
738 .
741 [i2rs-usecase]
742 Hares, S. and M. Chen, "Summary of I2RS Use Case
743 Requirements", March 2016,
744 .
747 [OMG-DDS] "Data Distribution Service for Real-time Systems, version
748 1.2", January 2007, .
750 [sacm-requirements]
751 Cam Winget, N., "Secure Automation and Continuous
752 Monitoring (SACM) Requirements", March 2016,
753 .
756 [XEP-0060]
757 Millard, P., "XEP-0060: Publish-Subscribe", July 2010,
758 .
760 Authors' Addresses
762 Eric Voit
763 Cisco Systems
765 Email: evoit@cisco.com
766 Alexander Clemm
767 Cisco Systems
769 Email: alex@cisco.com
771 Alberto Gonzalez Prieto
772 Cisco Systems
774 Email: albertgo@cisco.com