idnits 2.17.1 draft-ietf-i2rs-ephemeral-state-18.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 (September 20, 2016) is 2767 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC7921' is mentioned on line 474, but not defined == Missing Reference: 'RFC6241' is mentioned on line 459, but not defined == Missing Reference: 'I-D.ietf-netconf-restconf' is mentioned on line 454, but not defined == Missing Reference: 'RFC7923' is mentioned on line 484, but not defined == Missing Reference: 'RFC7922' is mentioned on line 479, but not defined == Missing Reference: 'I-D.ietf-i2rs-protocol-security-requirements' is mentioned on line 444, but not defined == Missing Reference: 'RFC6614' is mentioned on line 464, but not defined == Missing Reference: 'RFC6733' is mentioned on line 469, but not defined == Missing Reference: 'I-D.ietf-i2rs-security-environment-reqs' is mentioned on line 449, but not defined Summary: 0 errors (**), 0 flaws (~~), 10 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: March 24, 2017 Huawei 6 September 20, 2016 8 I2RS Ephemeral State Requirements 9 draft-ietf-i2rs-ephemeral-state-18.txt 11 Abstract 13 The I2RS (interface to routing system) Architecture document 14 (RFC7920) abstractly describes a number of requirements for ephemeral 15 state (in terms of capabilities and behaviors) which any protocol 16 suite attempting to meet I2RS needs has to provide. This document 17 describes in detail requirements for ephemeral state for those 18 implementing the I2RS higher-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 March 24, 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 . . . . . . . . . . . . . . . . 5 58 3.1. Persistence . . . . . . . . . . . . . . . . . . . . . . . 5 59 3.2. Constraints . . . . . . . . . . . . . . . . . . . . . . . 5 60 3.3. Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . 6 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 . . . . . . . . . . . . . . . . . . . . . . . 7 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 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 3. suggest protocol strawman (e.g. 107 [I-D.hares-i2rs-protocol-strawman]) as ideas for the NETCONF, 108 RESTCONF, and YANG changes. 110 The purpose of these requirements and the suggested protocol straw 111 man is to provide a quick turnaround on creating the I2RS protocol. 113 Support for ephemeral state is an I2RS protocol requirement that 114 requires datastore changes (see section 3), YANG additions (see 115 section 4), NETCONF additions (see section 5), and RESTCONF additions 116 (see section 6). 118 Sections 7-9 provide details that expand upon the changes in sections 119 3-6 to clarify requirements discussed by the I2RS and NETCONF working 120 groups. Section 7 provided additional requirements that detail how 121 write-conflicts should be resolved if two I2RS client write the same 122 data. Section 8 describes I2RS requirements for support of multiple 123 message transactions. Section 9 highlights two requirements in the 124 I2RS publication/subscription requirements [RFC7923] that must be 125 expanded for ephemeral state. 127 1.1. Requirements Language 129 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 130 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 131 document are to be interpreted as described in RFC 2119 [RFC2119]. 133 2. Review of Requirements from I2RS architecture document 135 The I2RS architecture defines important high-level requirements for 136 the I2RS protocol. The following are ten requirements that [RFC7921] 137 contains which provide context for the ephemeral data state 138 requirements given in sections 3-8: 140 1. The I2RS protocol SHOULD support highly reliable notifications 141 (but not perfectly reliable notifications) from an I2RS agent to 142 an I2RS client. 144 2. The I2RS protocol SHOULD support a high bandwidth, asynchronous 145 interface, with real-time guarantees on getting data from an 146 I2RS agent by an I2RS client. 148 3. The I2RS protocol will operate on data models which MAY be 149 protocol independent or protocol dependent. 151 4. I2RS agent MUST record the client identity when a node is 152 created or modified. The I2RS agent SHOULD to be able to read 153 the client identity of a node and use the client identity's 154 associated priority to resolve conflicts. The secondary 155 identity is useful for traceability and may also be recorded. 157 5. client identity MUST have only one priority for the client's 158 identifier. A collision on writes is considered an error, but 159 the priority associated with each client identifier is utilized 160 to compare requests from two different clients in order to 161 modify an existing node entry. Only an entry from a client 162 which is higher priority can modify an existing entry (First 163 entry wins). Priority only has meaning at the time of use. 165 6. The agent identity and the client identity SHOULD be passed 166 outside of the I2RS protocol in a authentication and 167 authorization protocol (AAA). client priority may be passed in 168 the AAA protocol. The values of identities are originally set 169 by operators, and not standardized. 171 7. An I2RS client and I2RS agent MUST mutually authenticate each 172 other based on pre-established authenticated identities. 174 8. Secondary identity data is read-only meta-data that is recorded 175 by the I2RS agent associated with a data model's node is 176 written, updated or deleted. Just like the primary identity, 177 the secondary identity SHOULD only be recorded when the data 178 node is written or updated or deleted 180 9. I2RS agent MAY have a lower priority I2RS client attempting to 181 modify a higher priority client's entry in a data model. The 182 filtering out of lower priority clients attempting to write or 183 modify a higher priority client's entry in a data model SHOULD 184 be effectively handled and not put an undue strain on the I2RS 185 agent. 187 10. The I2RS protocol MUST support the use of a secure transport. 188 However, certain functions such as notifications MAY use a non- 189 secure transport. Each model or service (notification, logging) 190 must define within the model or service the valid uses of a non- 191 secure transport. 193 3. Ephemeral State Requirements 195 In requirements Ephemeral-REQ-01 to Ephemeral-REQ-15, Ephemeral state 196 is defined as potentially including in a data model ephemeral 197 configuration and operational state which is flagged as ephemeral. 199 3.1. Persistence 201 Ephemeral-REQ-01: I2RS requires ephemeral state; i.e. state that does 202 not persist across reboots. If state must be restored, it should be 203 done solely by replay actions from the I2RS client via the I2RS 204 agent. 206 While at first glance this may seem equivalent to the writable- 207 running data store in NETCONF, running-config can be copied to a 208 persistent data store, like startup config. I2RS ephemeral state 209 MUST NOT be persisted. 211 3.2. Constraints 213 Ephemeral-REQ-02: Non-ephemeral state MUST NOT refer to ephemeral 214 state for constraint purposes; it SHALL be considered a validation 215 error if it does. 217 Ephemeral-REQ-03: Ephemeral state MUST be able to have constraints 218 that refer to operational state, this includes potentially fast 219 changing or short lived operational state nodes, such as MPLS LSP-ID 220 or a BGP IN-RIB. Ephemeral state constraints should be assessed when 221 the ephemeral state is written, and if any of the constraints change 222 to make the constraints invalid after that time the I2RS agent SHOULD 223 notify the I2RS client. 225 Ephemeral-REQ-04: Ephemeral state MUST be able to refer to non- 226 ephemeral state as a constraint. Non-ephemeral state can be 227 configuration state or operational state. 229 Ephemeral-REQ-05: I2RS pub-sub [RFC7923], tracing [RFC7922], RPC or 230 other mechanisms may lead to undesirable or unsustainable resource 231 consumption on a system implementing an I2RS agent. It is 232 RECOMMENDED that mechanisms be made available to permit 233 prioritization of I2RS operations, when appropriate, to permit 234 implementations to shed work load when operating under constrained 235 resources. An example of such a work shedding mechanism is rate- 236 limiting. 238 3.3. Hierarchy 240 Ephemeral-REQ-06: YANG MUST have the ability to do the following: 242 1. to define a YANG module or submodule schema that only contains 243 data nodes with the property of being ephemeral, and 245 2. to augment a YANG data model with additional YANG schema nodes 246 that have the property of being ephemeral. 248 3.4. Ephemeral Configuration overlapping Local Configuration 250 Ephemeral-REQ-07: Local configuration MUST have a priority that is 251 comparable with individual I2RS client priorities for making changes. 252 This priority will determine whether local configuration changes or 253 individual ephemeral configuration changes take precedence as 254 described in RFC7921. The I2RS protocol MUST support this mechanism. 256 4. YANG Features for Ephemeral State 258 Ephemeral-REQ-08:In addition to config true/false, there MUST be a 259 way to indicate that YANG schema nodes represent ephemeral state. It 260 is desirable to allow for, and have a way to indicate, config false 261 YANG schema nodes that are writable operational state. 263 5. NETCONF Features for Ephemeral State 265 Ephemeral-REQ-09: The changes to NETCONF must include: 267 1. Support for communication mechanisms to enable an I2RS client to 268 determine that an I2RS agent supports the mechanisms needed for 269 I2RS operation. 271 2. The ephemeral state MUST support notification of write conflicts 272 using the priority requirements defined in section 7 below in 273 requirements Ephemeral-REQ-11 through Ephemeral-REQ-14). 275 6. RESTCONF Features for Ephemeral State 277 Ephemeral-REQ-10: The conceptual changes to RESTCONF are: 279 1. Support for communication mechanisms to enable an I2RS client to 280 determine that an I2RS agent supports the mechanisms needed for 281 I2RS operation. 283 2. The ephemeral state must support notification of write conflicts 284 using the priority requirements defined in section 7 below in 285 requirements Ephemeral-REQ-11 through Ephemeral-REQ-14). 287 7. Requirements regarding Supporting Multi-Head Control via client 288 Priority 290 To support Multi-Headed Control, I2RS requires that there be a 291 decidable means of arbitrating the correct state of data when 292 multiple clients attempt to manipulate the same piece of data. This 293 is done via a priority mechanism with the highest priority winning. 294 This priority is per-client. 296 Ephemeral-REQ-11: The following requirements must be supported by the 297 I2RS protocol I2RS Protocol (e.g. NETCONF/RESTCONF + yang) in order 298 to support I2RS client identity and priority: 300 o the data nodes MAY store I2RS client identity and not the 301 effective priority at the time the data node is stored. 303 o Per SEC-REQ-07 in section 4.3 of 304 [I-D.ietf-i2rs-protocol-security-requirements], an I2RS Identifier 305 MUST have just one priority. The I2RS protocol MUST support the 306 ability to have data nodes store I2RS client identity and not the 307 effective priority of the I2RS client at the time the data node is 308 stored. 310 o The priority MAY be dynamically changed by AAA, but the exact 311 actions are part of the protocol definition as long as collisions 312 are handled as described in Ephemeral-REQ-12, Ephemeral-REQ-13, 313 and Ephemeral-REQ-14. 315 Ephemeral-REQ-12: When a collision occurs as two clients are trying 316 to write the same data node, this collision is considered an error 317 and priorities were created to give a deterministic result. When 318 there is a collision, a notification (which includes indicating data 319 node the collision occurred on) MUST BE sent to the original client 320 to give the original client a chance to deal with the issues 321 surrounding the collision. The original client may need to fix their 322 state. 324 Explanation: RESTCONF and NETCONF updates can come in concurrently 325 from alternative sources. Therefore the collision detection and 326 comparison of priority needs to occur for any type of update. 328 For example, RESTCONF tracks the source of configuration change via 329 the entity-Tag (section 3.5.2 of [I-D.ietf-netconf-restconf]) which 330 the server returns to the client along with the value in GET or HEAD 331 methods. RESTCONF requires that this resource entity-tag be updated 332 whenever a resource or configuration resource within the resource is 333 altered. In the RESTCONF processing, when the resource or a 334 configuration resource within the resource is altered, then the 335 processing of the configuration change for two I2RS clients must 336 detect an I2RS collision and resolve the collision using the priority 337 mechanism. 339 Ephemeral-REQ-13: Multi-headed control is required for collisions and 340 the priority resolution of collisions. Multi-headed control is not 341 tied to ephemeral state. I2RS protocol MUST NOT mandate the internal 342 mechanism for how AAA protocols (E.g. Radius or Diameter) or 343 mechanisms distribute priority per identity except that any AAA 344 protocols MUST operate over a secure transport layer (See Radius 345 [RFC6614] and Diameter [RFC6733]. Mechanisms that prevent collisions 346 of two clients trying to modify the same node of data are the focus. 348 Ephemeral-REQ-14: A deterministic conflict resolution mechanism MUST 349 be provided to handle the error scenario that two clients, with the 350 same priority, update the same configuration data node. The I2RS 351 architecture gives one way that this could be achieved, by specifying 352 that the first update wins. Other solutions, that prevent 353 oscillation of the config data node, are also acceptable. 355 8. Multiple Message Transactions 357 Ephemeral-REQ-15: Section 7.9 of the [RFC7921] states the I2RS 358 architecture does not include multi-message atomicity and roll-back 359 mechanisms. The I2RS protocol implementation MUST NOT require the 360 support of these features. As part of this requirement, the I2RS 361 protocol should support: 363 multiple operations in one or more messages; though errors in 364 message or operation will have no effect on other messages or 365 commands even they are related. 367 No multi-message commands SHOULD cause errors to be inserted into 368 the I2RS ephemeral state. 370 9. Pub/Sub Requirements Expanded for Ephemeral State 372 I2RS clients require the ability to monitor changes to ephemeral 373 state. While subscriptions are well defined for receiving 374 notifications, the need to create a notification set for all 375 ephemeral configuration state may be overly burdensome to the user. 377 There is thus a need for a general subscription mechanism that can 378 provide notification of changed state, with sufficient information to 379 permit the client to retrieve the impacted nodes. This should be 380 doable without requiring the notifications to be created as part of 381 every single I2RS module. 383 The publication/subscription requirements for I2RS are in [RFC7923], 384 and the following general requirements SHOULD be understood to be 385 expanded to include ephemeral state: 387 o Pub-Sub-REQ-01: The Subscription Service MUST support 388 subscriptions against ephemeral state in operational data stores, 389 configuration data stores or both. 391 o Pub-Sub-REQ-02: The Subscription Service MUST support filtering so 392 that subscribed updates under a target node might publish only 393 ephemeral state in operational data or configuration data, or 394 publish both ephemeral and operational data. 396 o Pub-Sub-REQ-03: The subscription service must support 397 subscriptions which are ephemeral. (E.g. An ephemeral data model 398 which has ephemeral subscriptions.) 400 10. IANA Considerations 402 There are no IANA requirements for this document. 404 11. Security Considerations 406 The security requirements for the I2RS protocol are covered in 407 [I-D.ietf-i2rs-protocol-security-requirements] document. The 408 security requirements for the I2RS protocol environment are in 409 [I-D.ietf-i2rs-security-environment-reqs]. 411 12. Acknowledgements 413 This document is an attempt to distill lengthy conversations on the 414 I2RS mailing list for an architecture that was for a long period of 415 time a moving target. Some individuals in particular warrant 416 specific mention for their extensive help in providing the basis for 417 this document: 419 o Alia Atlas, 421 o Andy Bierman, 423 o Martin Bjorklund, 425 o Dean Bogdanavich, 427 o Rex Fernando, 429 o Joel Halpern, 430 o Thomas Nadeau, 432 o Juergen Schoenwaelder, 434 o Kent Watsen, 436 o Robert Wilton, and 438 o Joe Clarke, 440 13. References 442 13.1. Normative References: 444 [I-D.ietf-i2rs-protocol-security-requirements] 445 Hares, S., Migault, D., and J. Halpern, "I2RS Security 446 Related Requirements", draft-ietf-i2rs-protocol-security- 447 requirements-11 (work in progress), September 2016. 449 [I-D.ietf-i2rs-security-environment-reqs] 450 Migault, D., Halpern, J., and S. Hares, "I2RS Environment 451 Security Requirements", draft-ietf-i2rs-security- 452 environment-reqs-01 (work in progress), April 2016. 454 [I-D.ietf-netconf-restconf] 455 Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 456 Protocol", draft-ietf-netconf-restconf-16 (work in 457 progress), August 2016. 459 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 460 and A. Bierman, Ed., "Network Configuration Protocol 461 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 462 . 464 [RFC6614] Winter, S., McCauley, M., Venaas, S., and K. Wierenga, 465 "Transport Layer Security (TLS) Encryption for RADIUS", 466 RFC 6614, DOI 10.17487/RFC6614, May 2012, 467 . 469 [RFC6733] Fajardo, V., Ed., Arkko, J., Loughney, J., and G. Zorn, 470 Ed., "Diameter Base Protocol", RFC 6733, 471 DOI 10.17487/RFC6733, October 2012, 472 . 474 [RFC7921] Atlas, A., Halpern, J., Hares, S., Ward, D., and T. 475 Nadeau, "An Architecture for the Interface to the Routing 476 System", RFC 7921, DOI 10.17487/RFC7921, June 2016, 477 . 479 [RFC7922] Clarke, J., Salgueiro, G., and C. Pignataro, "Interface to 480 the Routing System (I2RS) Traceability: Framework and 481 Information Model", RFC 7922, DOI 10.17487/RFC7922, June 482 2016, . 484 [RFC7923] Voit, E., Clemm, A., and A. Gonzalez Prieto, "Requirements 485 for Subscription to YANG Datastores", RFC 7923, 486 DOI 10.17487/RFC7923, June 2016, 487 . 489 13.2. Informative References 491 [I-D.hares-i2rs-protocol-strawman] 492 Hares, S. and a. amit.dass@ericsson.com, "I2RS protocol 493 strawman", draft-hares-i2rs-protocol-strawman-03 (work in 494 progress), July 2016. 496 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 497 Requirement Levels", BCP 14, RFC 2119, 498 DOI 10.17487/RFC2119, March 1997, 499 . 501 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 502 the Network Configuration Protocol (NETCONF)", RFC 6020, 503 DOI 10.17487/RFC6020, October 2010, 504 . 506 Authors' Addresses 508 Jeff Haas 509 Juniper 511 Email: jhaas@juniper.net 513 Susan Hares 514 Huawei 515 Saline 516 US 518 Email: shares@ndzh.com