idnits 2.17.1 draft-ietf-i2rs-ephemeral-state-23.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 (November 16, 2016) is 2690 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC7921' is mentioned on line 472, but not defined == Missing Reference: 'RFC7950' is mentioned on line 487, but not defined == Missing Reference: 'RFC6241' is mentioned on line 452, but not defined == Missing Reference: 'I-D.ietf-netconf-restconf' is mentioned on line 447, but not defined == Missing Reference: 'RFC7923' is mentioned on line 482, but not defined == Missing Reference: 'RFC7920' is mentioned on line 467, but not defined == Missing Reference: 'RFC7922' is mentioned on line 477, but not defined == Missing Reference: 'I-D.ietf-i2rs-protocol-security-requirements' is mentioned on line 437, but not defined == Missing Reference: 'RFC6614' is mentioned on line 457, but not defined == Missing Reference: 'RFC6733' is mentioned on line 462, but not defined == Missing Reference: 'I-D.ietf-i2rs-security-environment-reqs' is mentioned on line 442, but not defined Summary: 0 errors (**), 0 flaws (~~), 12 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 I2RS working group J. Haas 3 Internet-Draft Juniper 4 Intended status: Informational S. Hares 5 Expires: May 20, 2017 Huawei 6 November 16, 2016 8 I2RS Ephemeral State Requirements 9 draft-ietf-i2rs-ephemeral-state-23.txt 11 Abstract 13 The I2RS (interface to the routing system) Architecture document 14 (RFC7921) abstractly describes a number of requirements for ephemeral 15 state (in terms of capabilities and behaviors) which any protocol 16 suite attempting to meet the needs of I2RS has to provide. This 17 document describes, in detail, requirements for ephemeral state for 18 those implementing the I2RS protocol. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on May 20, 2017. 37 Copyright Notice 39 Copyright (c) 2016 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 56 2. Architectural Requirements for Ephemeral State . . . . . . . 3 57 3. Ephemeral State Requirements . . . . . . . . . . . . . . . . 4 58 3.1. Persistence . . . . . . . . . . . . . . . . . . . . . . . 5 59 3.2. Constraints . . . . . . . . . . . . . . . . . . . . . . . 5 60 3.3. Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . 5 61 3.4. Ephemeral Configuration overlapping Local Configuration . 6 62 4. YANG Features for Ephemeral State . . . . . . . . . . . . . . 6 63 5. NETCONF Features for Ephemeral State . . . . . . . . . . . . 6 64 6. RESTCONF Features for Ephemeral State . . . . . . . . . . . . 6 65 7. Requirements regarding Supporting Multi-Head Control via 66 client Priority . . . . . . . . . . . . . . . . . . . . . . . 6 67 8. Multiple Message Transactions . . . . . . . . . . . . . . . . 8 68 9. Pub/Sub Requirements Expanded for Ephemeral State . . . . . . 8 69 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 70 11. Security Considerations . . . . . . . . . . . . . . . . . . . 9 71 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 72 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 73 13.1. Normative References: . . . . . . . . . . . . . . . . . 10 74 13.2. Informative References . . . . . . . . . . . . . . . . . 11 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 77 1. Introduction 79 The Interface to the Routing System (I2RS) Working Group is chartered 80 with providing architecture and mechanisms to inject into and 81 retrieve information from the routing system. The I2RS Architecture 82 document [RFC7921] abstractly documents a number of requirements for 83 implementing the I2RS, and defines ephemeral state as "state which 84 does not survive the reboot of a routing device or the reboot of the 85 software handling the I2RS software on a routing device" (see section 86 1.1 of [RFC7921]). Section 2 describes the specific requirements 87 which the I2RS working group has identified based on the I2RS 88 architecture's abstract requirements. 90 The I2RS Working Group has chosen to use the YANG data modeling 91 language [RFC7950] as the basis to implement its mechanisms. 93 Additionally, the I2RS Working group has chosen to re-use two 94 existing protocols, NETCONF [RFC6241] and its similar but lighter- 95 weight relative RESTCONF [I-D.ietf-netconf-restconf], as the 96 protocols for carrying I2RS. 98 What does re-use of a protocol mean? Re-use means that while the 99 combination of the YANG modeling language, and the NETCONF and 100 RESTCONF protocols is a good starting basis for the I2RS data 101 modeling language and protocol, the creation of I2RS protocol 102 implementations requires that the I2RS requirements: 104 1. select features from the YANG modeling language, and the NETCONF 105 and RESTCONF protocols per version of the I2RS protocol (See 106 sections 4, 5, and 6) 108 2. propose additions to YANG, NETCONF, and RESTCONF per version of 109 the I2RS protocol for key functions (ephemeral state, protocol 110 security, publication/subscription service, traceability), 112 The purpose of these requirements is to ensure clarity during I2RS 113 protocol creation. 115 Support for ephemeral state is an I2RS protocol requirement that 116 requires datastore changes (see section 3), YANG additions (see 117 section 4), NETCONF additions (see section 5), and RESTCONF additions 118 (see section 6). 120 Sections 7-9 provide details that expand upon the changes in sections 121 3-6 to clarify requirements discussed by the I2RS and NETCONF working 122 groups. Section 7 provides additional requirements that detail how 123 write-conflicts should be resolved if two I2RS client write the same 124 data. Section 8 describes I2RS requirements for support of multiple 125 message transactions. Section 9 highlights two requirements in the 126 I2RS publication/subscription requirements [RFC7923] that must be 127 expanded for ephemeral state. 129 1.1. Requirements Language 131 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 132 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 133 document are to be interpreted as described in RFC 2119 [RFC2119]. 135 2. Architectural Requirements for Ephemeral State 137 The I2RS architecture [RFC7921] and the I2RS problem statement 138 [RFC7920] define the important high-level requirements for the I2RS 139 protocol in abstract terms. This section distills this high level 140 abstract guidance into specific requirements for the I2RS protocol. 141 To aid the reader, there are references back to the abstract 142 descriptions in the I2RS architecture document and the I2RS problem 143 statement, but the reader should note the requirements below are not 144 explicitly stated in the I2RS architecture document [RFC7921] or in 145 the I2RS problem statement [RFC7920]/ 146 Requirements: 148 1. The I2RS protocol SHOULD support an asynchronous programmatic 149 interface with properties of described in section 5 of [RFC7920] 150 (e.g. high throughput) with support for target information 151 streams, filtered events, and thresholded events (real-time 152 events) sent by an I2RS agent to an I2RS client (from section 1.1 153 of [RFC7921]). 155 2. I2RS agent MUST record the client identity when a node is created 156 or modified. The I2RS agent SHOULD to be able to read the client 157 identity of a node and use the client identity's associated 158 priority to resolve conflicts. The secondary identity is useful 159 for traceability and may also be recorded. (from section 4 of 160 [RFC7921].) 162 3. An I2RS client identity MUST have only one priority for the 163 client's identifier. A collision on writes is considered an 164 error, but the priority associated with each client identifier is 165 utilized to compare requests from two different clients in order 166 to modify an existing node entry. Only an entry from a client 167 which is higher priority can modify an existing entry (First 168 entry wins). Priority only has meaning at the time of use. (from 169 section 7.8 of [RFC7921].) 171 4. I2RS client's secondary identity data is read-only meta-data that 172 is recorded by the I2RS agent associated with a data model's node 173 is written. Just like the primary client identity, the secondary 174 identity SHOULD only be recorded when the data node is written. 175 (from sections 7.4 of [RFC7921].) 177 5. I2RS agent MAY have a lower priority I2RS client attempting to 178 modify a higher priority client's entry in a data model. The 179 filtering out of lower priority clients attempting to write or 180 modify a higher priority client's entry in a data model SHOULD be 181 effectively handled and not put an undue strain on the I2RS 182 agent. (See section 7.8 of [RFC7921] augmented by the resource 183 limitation language in section 8 [RFC7921].) 185 3. Ephemeral State Requirements 187 In requirements Ephemeral-REQ-01 to Ephemeral-REQ-15, Ephemeral state 188 is defined as potentially including in a data model ephemeral 189 configuration and operational state which is flagged as ephemeral. 191 3.1. Persistence 193 Ephemeral-REQ-01: I2RS requires ephemeral state; i.e. state that does 194 not persist across reboots. If state must be restored, it should be 195 done solely by replay actions from the I2RS client via the I2RS 196 agent. 198 While at first glance this may seem equivalent to the writable- 199 running data store in NETCONF, running-config can be copied to a 200 persistent data store, like startup config. I2RS ephemeral state 201 MUST NOT be persisted. 203 3.2. Constraints 205 Ephemeral-REQ-02: Non-ephemeral state MUST NOT refer to ephemeral 206 state for constraint purposes; it SHALL be considered a validation 207 error if it does. 209 Ephemeral-REQ-03: Ephemeral state MUST be able to have constraints 210 that refer to operational state, this includes potentially fast 211 changing or short lived operational state nodes, such as MPLS LSP-ID 212 (label switched path ID) or a BGP Adj-RIB-IN (Adjacent RIB Inboud). 213 Ephemeral state constraints should be assessed when the ephemeral 214 state is written, and if any of the constraints change to make the 215 constraints invalid after that time the I2RS agent SHOULD notify the 216 I2RS client. 218 Ephemeral-REQ-04: Ephemeral state MUST be able to refer to non- 219 ephemeral state as a constraint. Non-ephemeral state can be 220 configuration state or operational state. 222 Ephemeral-REQ-05: I2RS pub-sub [RFC7923], tracing [RFC7922], RPC or 223 other mechanisms may lead to undesirable or unsustainable resource 224 consumption on a system implementing an I2RS agent. It is 225 RECOMMENDED that mechanisms be made available to permit 226 prioritization of I2RS operations, when appropriate, to permit 227 implementations to shed work load when operating under constrained 228 resources. An example of such a work shedding mechanism is rate- 229 limiting. 231 3.3. Hierarchy 233 Ephemeral-REQ-06: YANG MUST have the ability to do the following: 235 1. to define a YANG module or submodule schema that only contains 236 data nodes with the property of being ephemeral, and 238 2. to augment a YANG model with additional YANG schema nodes that 239 have the property of being ephemeral. 241 3.4. Ephemeral Configuration overlapping Local Configuration 243 Ephemeral-REQ-07: Local configuration MUST have a priority that is 244 comparable with individual I2RS client priorities for making changes. 245 This priority will determine whether local configuration changes or 246 individual ephemeral configuration changes take precedence as 247 described in RFC7921. The I2RS protocol MUST support this mechanism. 249 4. YANG Features for Ephemeral State 251 Ephemeral-REQ-08:In addition to config true/false, there MUST be a 252 way to indicate that YANG schema nodes represent ephemeral state. It 253 is desirable to allow for, and have a way to indicate, config false 254 YANG schema nodes that are writable operational state. 256 5. NETCONF Features for Ephemeral State 258 Ephemeral-REQ-09: The changes to NETCONF must include: 260 1. Support for communication mechanisms to enable an I2RS client to 261 determine that an I2RS agent supports the mechanisms needed for 262 I2RS operation. 264 2. The ephemeral state MUST support notification of write conflicts 265 using the priority requirements defined in section 7 below (see 266 requirements Ephemeral-REQ-11 through Ephemeral-REQ-14). 268 6. RESTCONF Features for Ephemeral State 270 Ephemeral-REQ-10: The conceptual changes to RESTCONF are: 272 1. Support for communication mechanisms to enable an I2RS client to 273 determine that an I2RS agent supports the mechanisms needed for 274 I2RS operation. 276 2. The ephemeral state MUST support notification of write conflicts 277 using the priority requirements defined in section 7 below (see 278 requirements Ephemeral-REQ-11 through Ephemeral-REQ-14). 280 7. Requirements regarding Supporting Multi-Head Control via client 281 Priority 283 To support multi-headed control, I2RS requires that there be a 284 decidable means of arbitrating the correct state of data when 285 multiple clients attempt to manipulate the same piece of data. This 286 is done via a priority mechanism with the highest priority winning. 287 This priority is per-client. 289 Ephemeral-REQ-11: The following requirements must be supported by the 290 I2RS protocol in order to support I2RS client identity and priority: 292 o the data nodes MUST store I2RS client identity and MAY store the 293 effective priority at the time the data node is stored. 295 o Per SEC-REQ-07 in section 4.3 of 296 [I-D.ietf-i2rs-protocol-security-requirements], an I2RS Identifier 297 MUST have just one priority. The I2RS protocol MUST support the 298 ability to have data nodes store I2RS client identity and not the 299 effective priority of the I2RS client at the time the data node is 300 stored. 302 o The priority MAY be dynamically changed by AAA, but the exact 303 actions are part of the protocol definition as long as collisions 304 are handled as described in Ephemeral-REQ-12, Ephemeral-REQ-13, 305 and Ephemeral-REQ-14. 307 Ephemeral-REQ-12: When a collision occurs as two I2RS clients are 308 trying to write the same data node, this collision is considered an 309 error. The I2RS priorities are used to provide a deterministic 310 resolution to the conflict. When there is a collision, and the data 311 node is changed, a notification (which includes indicating data node 312 the collision occurred on) MUST be sent to the original client to 313 give the original client a chance to deal with the issues surrounding 314 the collision. The original client may need to fix their state. 316 Explanation: RESTCONF and NETCONF updates can come in concurrently 317 from alternative sources. Therefore the collision detection and 318 comparison of priority needs to occur for any type of update. 320 For example, RESTCONF tracks the source of configuration change via 321 the entity-Tag (section 3.5.2 of [I-D.ietf-netconf-restconf]) which 322 the server returns to the client along with the value in GET or HEAD 323 methods. RESTCONF requires that this resource entity-tag be updated 324 whenever a resource or configuration resource within the resource is 325 altered. In the RESTCONF processing, when the resource or a 326 configuration resource within the resource is altered, then the 327 processing of the configuration change for two I2RS clients must 328 detect an I2RS collision and resolve the collision using the priority 329 mechanism. 331 Ephemeral-REQ-13: Multi-headed control is required for collisions and 332 the priority resolution of collisions. Multi-headed control is not 333 tied to ephemeral state. I2RS protocol MUST NOT mandate the internal 334 mechanism for how AAA protocols (E.g. Radius or Diameter) or 335 mechanisms distribute priority per identity except that any AAA 336 protocols MUST operate over a secure transport layer (See Radius 337 [RFC6614] and Diameter [RFC6733]. Mechanisms that prevent collisions 338 of two clients trying to modify the same node of data are the focus. 340 Ephemeral-REQ-14: A deterministic conflict resolution mechanism MUST 341 be provided to handle the error scenario that two clients, with the 342 same priority, update the same configuration data node. The I2RS 343 architecture gives one way that this could be achieved, by specifying 344 that the first update wins. Other solutions, that prevent 345 oscillation of the config data node, are also acceptable. 347 8. Multiple Message Transactions 349 Ephemeral-REQ-15: Section 7.9 of the [RFC7921] states the I2RS 350 architecture does not include multi-message atomicity and roll-back 351 mechanisms. The I2RS protocol implementation MUST NOT require the 352 support of these features. As part of this requirement, the I2RS 353 protocol should support: 355 multiple operations in one messge; an error in one operation MUST 356 NOT stop additional operations from being carried out nor can it 357 cause previous operations to be rolled back. 359 multiple operations in multiple messages, but multiple message 360 commands error handling MUST NOT insert errors into the I2RS 361 ephemeral state. 363 9. Pub/Sub Requirements Expanded for Ephemeral State 365 I2RS clients require the ability to monitor changes to ephemeral 366 state. While subscriptions are well defined for receiving 367 notifications, the need to create a notification set for all 368 ephemeral configuration state may be overly burdensome to the user. 370 There is thus a need for a general subscription mechanism that can 371 provide notification of changed state, with sufficient information to 372 permit the client to retrieve the impacted nodes. This should be 373 doable without requiring the notifications to be created as part of 374 every single I2RS module. 376 The publication/subscription requirements for I2RS are in [RFC7923], 377 and the following general requirements SHOULD be understood to be 378 expanded to include ephemeral state: 380 o Pub-Sub-REQ-01: The Subscription Service MUST support 381 subscriptions against ephemeral state in operational data stores, 382 configuration data stores or both. 384 o Pub-Sub-REQ-02: The Subscription Service MUST support filtering so 385 that subscribed updates under a target node might publish only 386 ephemeral state in operational data or configuration data, or 387 publish both ephemeral and operational data. 389 o Pub-Sub-REQ-03: The subscription service MUST support 390 subscriptions which are ephemeral. (E.g. An ephemeral data model 391 which has ephemeral subscriptions.) 393 10. IANA Considerations 395 There are no IANA requirements for this document. 397 11. Security Considerations 399 The security requirements for the I2RS protocol are covered in 400 [I-D.ietf-i2rs-protocol-security-requirements] document. The 401 security requirements for the I2RS protocol environment are in 402 [I-D.ietf-i2rs-security-environment-reqs]. 404 12. Acknowledgements 406 This document is an attempt to distill lengthy conversations on the 407 I2RS mailing list for an architecture that was for a long period of 408 time a moving target. Some individuals in particular warrant 409 specific mention for their extensive help in providing the basis for 410 this document: 412 o Alia Atlas, 414 o Andy Bierman, 416 o Martin Bjorklund, 418 o Dean Bogdanavich, 420 o Rex Fernando, 422 o Joel Halpern, 424 o Thomas Nadeau, 426 o Juergen Schoenwaelder, 427 o Kent Watsen, 429 o Robert Wilton, and 431 o Joe Clarke, 433 13. References 435 13.1. Normative References: 437 [I-D.ietf-i2rs-protocol-security-requirements] 438 Hares, S., Migault, D., and J. Halpern, "I2RS Security 439 Related Requirements", draft-ietf-i2rs-protocol-security- 440 requirements-17 (work in progress), September 2016. 442 [I-D.ietf-i2rs-security-environment-reqs] 443 Migault, D., Halpern, J., and S. Hares, "I2RS Environment 444 Security Requirements", draft-ietf-i2rs-security- 445 environment-reqs-02 (work in progress), November 2016. 447 [I-D.ietf-netconf-restconf] 448 Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 449 Protocol", draft-ietf-netconf-restconf-18 (work in 450 progress), October 2016. 452 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 453 and A. Bierman, Ed., "Network Configuration Protocol 454 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 455 . 457 [RFC6614] Winter, S., McCauley, M., Venaas, S., and K. Wierenga, 458 "Transport Layer Security (TLS) Encryption for RADIUS", 459 RFC 6614, DOI 10.17487/RFC6614, May 2012, 460 . 462 [RFC6733] Fajardo, V., Ed., Arkko, J., Loughney, J., and G. Zorn, 463 Ed., "Diameter Base Protocol", RFC 6733, 464 DOI 10.17487/RFC6733, October 2012, 465 . 467 [RFC7920] Atlas, A., Ed., Nadeau, T., Ed., and D. Ward, "Problem 468 Statement for the Interface to the Routing System", 469 RFC 7920, DOI 10.17487/RFC7920, June 2016, 470 . 472 [RFC7921] Atlas, A., Halpern, J., Hares, S., Ward, D., and T. 473 Nadeau, "An Architecture for the Interface to the Routing 474 System", RFC 7921, DOI 10.17487/RFC7921, June 2016, 475 . 477 [RFC7922] Clarke, J., Salgueiro, G., and C. Pignataro, "Interface to 478 the Routing System (I2RS) Traceability: Framework and 479 Information Model", RFC 7922, DOI 10.17487/RFC7922, June 480 2016, . 482 [RFC7923] Voit, E., Clemm, A., and A. Gonzalez Prieto, "Requirements 483 for Subscription to YANG Datastores", RFC 7923, 484 DOI 10.17487/RFC7923, June 2016, 485 . 487 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 488 RFC 7950, DOI 10.17487/RFC7950, August 2016, 489 . 491 13.2. Informative References 493 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 494 Requirement Levels", BCP 14, RFC 2119, 495 DOI 10.17487/RFC2119, March 1997, 496 . 498 Authors' Addresses 500 Jeff Haas 501 Juniper 503 Email: jhaas@juniper.net 505 Susan Hares 506 Huawei 507 Saline 508 US 510 Email: shares@ndzh.com