idnits 2.17.1 draft-ietf-i2rs-ephemeral-state-19.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 (October 5, 2016) is 2760 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC7921' is mentioned on line 450, but not defined == Missing Reference: 'RFC6241' is mentioned on line 435, but not defined == Missing Reference: 'I-D.ietf-netconf-restconf' is mentioned on line 430, but not defined == Missing Reference: 'RFC7923' is mentioned on line 460, but not defined == Missing Reference: 'RFC7922' is mentioned on line 455, but not defined == Missing Reference: 'I-D.ietf-i2rs-protocol-security-requirements' is mentioned on line 420, but not defined == Missing Reference: 'RFC6614' is mentioned on line 440, but not defined == Missing Reference: 'RFC6733' is mentioned on line 445, but not defined == Missing Reference: 'I-D.ietf-i2rs-security-environment-reqs' is mentioned on line 425, but not defined == Unused Reference: 'I-D.hares-i2rs-protocol-strawman' is defined on line 467, but no explicit reference was found in the text Summary: 0 errors (**), 0 flaws (~~), 11 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: April 8, 2017 Huawei 6 October 5, 2016 8 I2RS Ephemeral State Requirements 9 draft-ietf-i2rs-ephemeral-state-19.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 April 8, 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. Review of Requirements from I2RS architecture document . . . 3 57 3. Ephemeral State Requirements . . . . . . . . . . . . . . . . 4 58 3.1. Persistence . . . . . . . . . . . . . . . . . . . . . . . 4 59 3.2. Constraints . . . . . . . . . . . . . . . . . . . . . . . 4 60 3.3. Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . 5 61 3.4. Ephemeral Configuration overlapping Local Configuration . 5 62 4. YANG Features for Ephemeral State . . . . . . . . . . . . . . 5 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 . . . . . . . . . . . . . . . . . . . . . . . . . 9 73 13.1. Normative References: . . . . . . . . . . . . . . . . . 9 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 requirements. Section 2 reviews 10 key 84 requirements related to ephemeral state. 86 The I2RS Working Group has chosen to use the YANG data modeling 87 language [RFC6020] as the basis to implement its mechanisms. 89 Additionally, the I2RS Working group has chosen to re-use two 90 existing protocols, NETCONF [RFC6241] and its similar but lighter- 91 weight relative RESTCONF [I-D.ietf-netconf-restconf], as the 92 protocols for carrying I2RS. 94 What does re-use of a protocol mean? Re-use means that while YANG, 95 NETCONF and RESTCONF are a good starting basis for the I2RS protocol, 96 the creation of the I2RS protocol implementations requires that the 97 I2RS requirements 99 1. select features from YANG, NETCONF, and RESTCONF per version of 100 the I2RS protocol (See sections 4, 5, and 6) 102 2. propose additions to YANG, NETCONF, and RESTCONF per version of 103 the I2RS protocol for key functions (ephemeral state, protocol 104 security, publication/subscription service, traceability), 106 The purpose of these requirements is to ensure clarity during I2RS 107 protocol creation. 109 Support for ephemeral state is an I2RS protocol requirement that 110 requires datastore changes (see section 3), YANG additions (see 111 section 4), NETCONF additions (see section 5), and RESTCONF additions 112 (see section 6). 114 Sections 7-9 provide details that expand upon the changes in sections 115 3-6 to clarify requirements discussed by the I2RS and NETCONF working 116 groups. Section 7 provided additional requirements that detail how 117 write-conflicts should be resolved if two I2RS client write the same 118 data. Section 8 describes I2RS requirements for support of multiple 119 message transactions. Section 9 highlights two requirements in the 120 I2RS publication/subscription requirements [RFC7923] that must be 121 expanded for ephemeral state. 123 1.1. Requirements Language 125 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 126 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 127 document are to be interpreted as described in RFC 2119 [RFC2119]. 129 2. Review of Requirements from I2RS architecture document 131 The I2RS architecture defines important high-level requirements for 132 the I2RS protocol. The following are requirements distilled from 133 [RFC7921] that provide context for the ephemeral data state 134 requirements given in sections 3-8: 136 1. The I2RS protocol SHOULD support a high bandwidth, asynchronous 137 interface, with real-time guarantees on getting data from an I2RS 138 agent by an I2RS client. 140 2. I2RS agent MUST record the client identity when a node is created 141 or modified. The I2RS agent SHOULD to be able to read the client 142 identity of a node and use the client identity's associated 143 priority to resolve conflicts. The secondary identity is useful 144 for traceability and may also be recorded. 146 3. An I2RS Client identity MUST have only one priority for the 147 client's identifier. A collision on writes is considered an 148 error, but the priority associated with each client identifier is 149 utilized to compare requests from two different clients in order 150 to modify an existing node entry. Only an entry from a client 151 which is higher priority can modify an existing entry (First 152 entry wins). Priority only has meaning at the time of use. 154 4. I2RS Client's secondary identity data is read-only meta-data that 155 is recorded by the I2RS agent associated with a data model's node 156 is written. Just like the primary client identity, the secondary 157 identity SHOULD only be recorded when the data node is written. 159 5. I2RS agent MAY have a lower priority I2RS client attempting to 160 modify a higher priority client's entry in a data model. The 161 filtering out of lower priority clients attempting to write or 162 modify a higher priority client's entry in a data model SHOULD be 163 effectively handled and not put an undue strain on the I2RS 164 agent. 166 3. Ephemeral State Requirements 168 In requirements Ephemeral-REQ-01 to Ephemeral-REQ-15, Ephemeral state 169 is defined as potentially including in a data model ephemeral 170 configuration and operational state which is flagged as ephemeral. 172 3.1. Persistence 174 Ephemeral-REQ-01: I2RS requires ephemeral state; i.e. state that does 175 not persist across reboots. If state must be restored, it should be 176 done solely by replay actions from the I2RS client via the I2RS 177 agent. 179 While at first glance this may seem equivalent to the writable- 180 running data store in NETCONF, running-config can be copied to a 181 persistent data store, like startup config. I2RS ephemeral state 182 MUST NOT be persisted. 184 3.2. Constraints 186 Ephemeral-REQ-02: Non-ephemeral state MUST NOT refer to ephemeral 187 state for constraint purposes; it SHALL be considered a validation 188 error if it does. 190 Ephemeral-REQ-03: Ephemeral state MUST be able to have constraints 191 that refer to operational state, this includes potentially fast 192 changing or short lived operational state nodes, such as MPLS LSP-ID 193 (label switched path ID) or a BGP Adj-RIB-IN (Adjacent RIB Inboud). 194 Ephemeral state constraints should be assessed when the ephemeral 195 state is written, and if any of the constraints change to make the 196 constraints invalid after that time the I2RS agent SHOULD notify the 197 I2RS client. 199 Ephemeral-REQ-04: Ephemeral state MUST be able to refer to non- 200 ephemeral state as a constraint. Non-ephemeral state can be 201 configuration state or operational state. 203 Ephemeral-REQ-05: I2RS pub-sub [RFC7923], tracing [RFC7922], RPC or 204 other mechanisms may lead to undesirable or unsustainable resource 205 consumption on a system implementing an I2RS agent. It is 206 RECOMMENDED that mechanisms be made available to permit 207 prioritization of I2RS operations, when appropriate, to permit 208 implementations to shed work load when operating under constrained 209 resources. An example of such a work shedding mechanism is rate- 210 limiting. 212 3.3. Hierarchy 214 Ephemeral-REQ-06: YANG MUST have the ability to do the following: 216 1. to define a YANG module or submodule schema that only contains 217 data nodes with the property of being ephemeral, and 219 2. to augment a YANG model with additional YANG schema nodes that 220 have the property of being ephemeral. 222 3.4. Ephemeral Configuration overlapping Local Configuration 224 Ephemeral-REQ-07: Local configuration MUST have a priority that is 225 comparable with individual I2RS client priorities for making changes. 226 This priority will determine whether local configuration changes or 227 individual ephemeral configuration changes take precedence as 228 described in RFC7921. The I2RS protocol MUST support this mechanism. 230 4. YANG Features for Ephemeral State 232 Ephemeral-REQ-08:In addition to config true/false, there MUST be a 233 way to indicate that YANG schema nodes represent ephemeral state. It 234 is desirable to allow for, and have a way to indicate, config false 235 YANG schema nodes that are writable operational state. 237 5. NETCONF Features for Ephemeral State 239 Ephemeral-REQ-09: The changes to NETCONF must include: 241 1. Support for communication mechanisms to enable an I2RS client to 242 determine that an I2RS agent supports the mechanisms needed for 243 I2RS operation. 245 2. The ephemeral state MUST support notification of write conflicts 246 using the priority requirements defined in section 7 below (see 247 requirements Ephemeral-REQ-11 through Ephemeral-REQ-14). 249 6. RESTCONF Features for Ephemeral State 251 Ephemeral-REQ-10: The conceptual changes to RESTCONF are: 253 1. Support for communication mechanisms to enable an I2RS client to 254 determine that an I2RS agent supports the mechanisms needed for 255 I2RS operation. 257 2. The ephemeral state must support notification of write conflicts 258 using the priority requirements defined in section 7 below (see 259 requirements Ephemeral-REQ-11 through Ephemeral-REQ-14). 261 7. Requirements regarding Supporting Multi-Head Control via client 262 Priority 264 To support Multi-Headed Control, I2RS requires that there be a 265 decidable means of arbitrating the correct state of data when 266 multiple clients attempt to manipulate the same piece of data. This 267 is done via a priority mechanism with the highest priority winning. 268 This priority is per-client. 270 Ephemeral-REQ-11: The following requirements must be supported by the 271 I2RS protocol I2RS Protocol (e.g. NETCONF/RESTCONF + yang) in order 272 to support I2RS client identity and priority: 274 o the data nodes MAY store I2RS client identity and not the 275 effective priority at the time the data node is stored. 277 o Per SEC-REQ-07 in section 4.3 of 278 [I-D.ietf-i2rs-protocol-security-requirements], an I2RS Identifier 279 MUST have just one priority. The I2RS protocol MUST support the 280 ability to have data nodes store I2RS client identity and not the 281 effective priority of the I2RS client at the time the data node is 282 stored. 284 o The priority MAY be dynamically changed by AAA, but the exact 285 actions are part of the protocol definition as long as collisions 286 are handled as described in Ephemeral-REQ-12, Ephemeral-REQ-13, 287 and Ephemeral-REQ-14. 289 Ephemeral-REQ-12: When a collision occurs as two clients are trying 290 to write the same data node, this collision is considered an error 291 and priorities were created to give a deterministic result. When 292 there is a collision, and the data node is changed, a notification 293 (which includes indicating data node the collision occurred on) MUST 294 BE sent to the original client to give the original client a chance 295 to deal with the issues surrounding the collision. The original 296 client may need to fix their state. 298 Explanation: RESTCONF and NETCONF updates can come in concurrently 299 from alternative sources. Therefore the collision detection and 300 comparison of priority needs to occur for any type of update. 302 For example, RESTCONF tracks the source of configuration change via 303 the entity-Tag (section 3.5.2 of [I-D.ietf-netconf-restconf]) which 304 the server returns to the client along with the value in GET or HEAD 305 methods. RESTCONF requires that this resource entity-tag be updated 306 whenever a resource or configuration resource within the resource is 307 altered. In the RESTCONF processing, when the resource or a 308 configuration resource within the resource is altered, then the 309 processing of the configuration change for two I2RS clients must 310 detect an I2RS collision and resolve the collision using the priority 311 mechanism. 313 Ephemeral-REQ-13: Multi-headed control is required for collisions and 314 the priority resolution of collisions. Multi-headed control is not 315 tied to ephemeral state. I2RS protocol MUST NOT mandate the internal 316 mechanism for how AAA protocols (E.g. Radius or Diameter) or 317 mechanisms distribute priority per identity except that any AAA 318 protocols MUST operate over a secure transport layer (See Radius 319 [RFC6614] and Diameter [RFC6733]. Mechanisms that prevent collisions 320 of two clients trying to modify the same node of data are the focus. 322 Ephemeral-REQ-14: A deterministic conflict resolution mechanism MUST 323 be provided to handle the error scenario that two clients, with the 324 same priority, update the same configuration data node. The I2RS 325 architecture gives one way that this could be achieved, by specifying 326 that the first update wins. Other solutions, that prevent 327 oscillation of the config data node, are also acceptable. 329 8. Multiple Message Transactions 331 Ephemeral-REQ-15: Section 7.9 of the [RFC7921] states the I2RS 332 architecture does not include multi-message atomicity and roll-back 333 mechanisms. The I2RS protocol implementation MUST NOT require the 334 support of these features. As part of this requirement, the I2RS 335 protocol should support: 337 multiple operations in one messge; an error in one operation MUST 338 NOT stop additional operations from being carried out nor can it 339 cause previous operations to be rolled back. 341 multiple operations in multiple messages, but multiple message 342 commands error handling MUST NOT insert errors into the I2RS 343 ephemeral state. 345 9. Pub/Sub Requirements Expanded for Ephemeral State 347 I2RS clients require the ability to monitor changes to ephemeral 348 state. While subscriptions are well defined for receiving 349 notifications, the need to create a notification set for all 350 ephemeral configuration state may be overly burdensome to the user. 352 There is thus a need for a general subscription mechanism that can 353 provide notification of changed state, with sufficient information to 354 permit the client to retrieve the impacted nodes. This should be 355 doable without requiring the notifications to be created as part of 356 every single I2RS module. 358 The publication/subscription requirements for I2RS are in [RFC7923], 359 and the following general requirements SHOULD be understood to be 360 expanded to include ephemeral state: 362 o Pub-Sub-REQ-01: The Subscription Service MUST support 363 subscriptions against ephemeral state in operational data stores, 364 configuration data stores or both. 366 o Pub-Sub-REQ-02: The Subscription Service MUST support filtering so 367 that subscribed updates under a target node might publish only 368 ephemeral state in operational data or configuration data, or 369 publish both ephemeral and operational data. 371 o Pub-Sub-REQ-03: The subscription service must support 372 subscriptions which are ephemeral. (E.g. An ephemeral data model 373 which has ephemeral subscriptions.) 375 10. IANA Considerations 377 There are no IANA requirements for this document. 379 11. Security Considerations 381 The security requirements for the I2RS protocol are covered in 382 [I-D.ietf-i2rs-protocol-security-requirements] document. The 383 security requirements for the I2RS protocol environment are in 384 [I-D.ietf-i2rs-security-environment-reqs]. 386 12. Acknowledgements 388 This document is an attempt to distill lengthy conversations on the 389 I2RS mailing list for an architecture that was for a long period of 390 time a moving target. Some individuals in particular warrant 391 specific mention for their extensive help in providing the basis for 392 this document: 394 o Alia Atlas, 396 o Andy Bierman, 398 o Martin Bjorklund, 400 o Dean Bogdanavich, 402 o Rex Fernando, 404 o Joel Halpern, 406 o Thomas Nadeau, 408 o Juergen Schoenwaelder, 410 o Kent Watsen, 412 o Robert Wilton, and 414 o Joe Clarke, 416 13. References 418 13.1. Normative References: 420 [I-D.ietf-i2rs-protocol-security-requirements] 421 Hares, S., Migault, D., and J. Halpern, "I2RS Security 422 Related Requirements", draft-ietf-i2rs-protocol-security- 423 requirements-17 (work in progress), September 2016. 425 [I-D.ietf-i2rs-security-environment-reqs] 426 Migault, D., Halpern, J., and S. Hares, "I2RS Environment 427 Security Requirements", draft-ietf-i2rs-security- 428 environment-reqs-01 (work in progress), April 2016. 430 [I-D.ietf-netconf-restconf] 431 Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 432 Protocol", draft-ietf-netconf-restconf-17 (work in 433 progress), September 2016. 435 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 436 and A. Bierman, Ed., "Network Configuration Protocol 437 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 438 . 440 [RFC6614] Winter, S., McCauley, M., Venaas, S., and K. Wierenga, 441 "Transport Layer Security (TLS) Encryption for RADIUS", 442 RFC 6614, DOI 10.17487/RFC6614, May 2012, 443 . 445 [RFC6733] Fajardo, V., Ed., Arkko, J., Loughney, J., and G. Zorn, 446 Ed., "Diameter Base Protocol", RFC 6733, 447 DOI 10.17487/RFC6733, October 2012, 448 . 450 [RFC7921] Atlas, A., Halpern, J., Hares, S., Ward, D., and T. 451 Nadeau, "An Architecture for the Interface to the Routing 452 System", RFC 7921, DOI 10.17487/RFC7921, June 2016, 453 . 455 [RFC7922] Clarke, J., Salgueiro, G., and C. Pignataro, "Interface to 456 the Routing System (I2RS) Traceability: Framework and 457 Information Model", RFC 7922, DOI 10.17487/RFC7922, June 458 2016, . 460 [RFC7923] Voit, E., Clemm, A., and A. Gonzalez Prieto, "Requirements 461 for Subscription to YANG Datastores", RFC 7923, 462 DOI 10.17487/RFC7923, June 2016, 463 . 465 13.2. Informative References 467 [I-D.hares-i2rs-protocol-strawman] 468 Hares, S. and a. amit.dass@ericsson.com, "I2RS protocol 469 strawman", draft-hares-i2rs-protocol-strawman-03 (work in 470 progress), July 2016. 472 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 473 Requirement Levels", BCP 14, RFC 2119, 474 DOI 10.17487/RFC2119, March 1997, 475 . 477 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 478 the Network Configuration Protocol (NETCONF)", RFC 6020, 479 DOI 10.17487/RFC6020, October 2010, 480 . 482 Authors' Addresses 484 Jeff Haas 485 Juniper 487 Email: jhaas@juniper.net 489 Susan Hares 490 Huawei 491 Saline 492 US 494 Email: shares@ndzh.com