idnits 2.17.1 draft-ietf-i2rs-ephemeral-state-15.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 : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: Ephemeral-REQ-15: Section 7.9 of the [I-D.ietf-i2rs-architecture] states the I2RS architecture does not include multi-message atomicity and roll-back mechanisms. The I2RS protocol implementation MUST not require the support of these features. As part of this requirement, the I2SR protocol should support: -- The document date (July 21, 2016) is 2830 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'I-D.ietf-i2rs-architecture' is mentioned on line 425, but not defined == Missing Reference: 'RFC6241' is mentioned on line 457, but not defined == Missing Reference: 'I-D.ietf-netconf-restconf' is mentioned on line 452, but not defined == Missing Reference: 'I-D.ietf-i2rs-pub-sub-requirements' is mentioned on line 436, but not defined == Missing Reference: 'I-D.ietf-i2rs-protocol-security-requirements' is mentioned on line 431, but not defined == Missing Reference: 'I-D.ietf-i2rs-security-environment-reqs' is mentioned on line 441, but not defined == Missing Reference: 'I-D.ietf-i2rs-traceability' is mentioned on line 446, 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: Standards Track S. Hares 5 Expires: January 22, 2017 Huawei 6 July 21, 2016 8 I2RS Ephemeral State Requirements 9 draft-ietf-i2rs-ephemeral-state-15 11 Abstract 13 This document covers requests to the NETMOD and NETCONF Working 14 Groups for functionality to support the ephemeral state requirements 15 to implement the I2RS architecture. 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at http://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on January 22, 2017. 34 Copyright Notice 36 Copyright (c) 2016 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 52 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 53 2. Review of Requirements from I2RS architecture document . . . 3 54 3. Ephemeral State Requirements . . . . . . . . . . . . . . . . 5 55 3.1. Persistence . . . . . . . . . . . . . . . . . . . . . . . 5 56 3.2. Constraints . . . . . . . . . . . . . . . . . . . . . . . 5 57 3.3. Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . 6 58 3.4. Ephemeral Configuration overlapping Local Configuration . 6 59 4. YANG Features for Ephemeral State . . . . . . . . . . . . . . 6 60 5. NETCONF Features for Ephemeral State . . . . . . . . . . . . 6 61 6. RESTCONF Features for Ephemeral State . . . . . . . . . . . . 6 62 7. Requirements regarding Supporting Multi-Head Control via 63 Client Priority . . . . . . . . . . . . . . . . . . . . . . . 7 64 8. Multiple Message Transactions . . . . . . . . . . . . . . . . 8 65 9. Pub/Sub Requirements Expanded for Ephemeral State . . . . . . 8 66 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 67 11. Security Considerations . . . . . . . . . . . . . . . . . . . 9 68 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 69 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 70 13.1. Normative References: . . . . . . . . . . . . . . . . . 10 71 13.2. Informative References . . . . . . . . . . . . . . . . . 10 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 74 1. Introduction 76 The Interface to the Routing System (I2RS) Working Group is chartered 77 with providing architecture and mechanisms to inject into and 78 retrieve information from the routing system. The I2RS Architecture 79 document [I-D.ietf-i2rs-architecture] abstractly documents a number 80 of requirements for implementing the I2RS requirements. Section 2 81 reviews 10 key requirements related to ephemeral state. 83 The I2RS Working Group has chosen to use the YANG data modeling 84 language [RFC6020] as the basis to implement its mechanisms. 86 Additionally, the I2RS Working group has chosen to re-use two 87 existing protocols, NETCONF [RFC6241] and its similar but lighter- 88 weight relative RESTCONF [I-D.ietf-netconf-restconf], as the 89 protocols for carrying I2RS. 91 What does re-use of a protocol mean? Re-use means that while YANG, 92 NETCONF and RESTCONF are a good starting basis for the I2RS protocol, 93 the creation of the I2RS protocol implementations requires that the 94 I2RS requirements 95 1. select features from YANG, NETCONF, and RESTCONF per version of 96 the I2RS protocol (See sections 4, 5, and 6) 98 2. propose additions to YANG, NETCONF, and RESTCONF per version of 99 the I2RS protocol for key functions (ephemeral state, protocol 100 security, publication/subscription service, traceability), 102 3. suggest protocol strawman (e.g. 103 [I-D.hares-i2rs-protocol-strawman]) as ideas for the NETCONF, 104 RESTCONF, and YANG changes. 106 The purpose of these requirements and the suggested protocol straw 107 man is to provide a quick turnaround on creating the I2RS protocol. 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. Sections 7 provide additional requirements that detail how 117 write-conflicts should be resolved if two I2RS client write the same 118 data. Section 8 provides an additional requirement that details on 119 I2RS support of multiple message transactions. Section 9 highlights 120 two requirements in the I2RS publication/subscription requirements 121 [I-D.ietf-i2rs-pub-sub-requirements] that must be expanded for 122 ephemeral state. 124 1.1. Requirements Language 126 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 127 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 128 document are to be interpreted as described in RFC 2119 [RFC2119]. 130 2. Review of Requirements from I2RS architecture document 132 The I2RS architecture defines important high-level requirements for 133 the I2RS protocol. The following are ten requirements that 134 [I-D.ietf-i2rs-architecture] contains which provide context for the 135 ephemeral data state requirements given in sections 3-8: 137 1. The I2RS protocol SHOULD support highly reliable notifications 138 (but not perfectly reliable notifications) from an I2RS agent to 139 an I2RS client. 141 2. The I2RS protocol SHOULD support a high bandwidth, asynchronous 142 interface, with real-time guarantees on getting data from an 143 I2RS agent by an I2RS client. 145 3. The I2RS protocol will operate on data models which MAY be 146 protocol independent or protocol dependent. 148 4. I2RS Agent MUST record the client identity when a node is 149 created or modified. The I2RS Agent SHOULD to be able to read 150 the client identity of a node and use the client identity's 151 associated priority to resolve conflicts. The secondary 152 identity is useful for traceability and may also be recorded. 154 5. Client identity MUST have only one priority for the client's 155 identifier. A collision on writes is considered an error, but 156 the priority associated with each client identifier is utilized 157 to compare requests from two different clients in order to 158 modify an existing node entry. Only an entry from a client 159 which is higher priority can modify an existing entry (First 160 entry wins). Priority only has meaning at the time of use. 162 6. The Agent identity and the Client identity SHOULD be passed 163 outside of the I2RS protocol in a authentication and 164 authorization protocol (AAA). Client priority may be passed in 165 the AAA protocol. The values of identities are originally set 166 by operators, and not standardized. 168 7. An I2RS Client and I2RS Agent MUST mutually authenticate each 169 other based on pre-established authenticated identities. 171 8. Secondary identity data is read-only meta-data that is recorded 172 by the I2RS agent associated with a data model's node is 173 written, updated or deleted. Just like the primary identity, 174 the secondary identity SHOULD only be recorded when the data 175 node is written or updated or deleted 177 9. 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 181 be effectively handled and not put an undue strain on the I2RS 182 agent. 184 10. The I2RS protocol MUST support the use of a secure transport. 185 However, certain functions such as notifications MAY use a non- 186 secure transport. Each model or service (notification, logging) 187 must define within the model or service the valid uses of a non- 188 secure transport. 190 3. Ephemeral State Requirements 192 In requirements Ephemeral-REQ-01 to Ephemeral-15, Ephemeral state is 193 defined as potentially including both ephemeral configured state and 194 operational state. 196 3.1. Persistence 198 Ephemeral-REQ-01: I2RS requires ephemeral state; i.e. state that does 199 not persist across reboots. If state must be restored, it should be 200 done solely by replay actions from the I2RS client via the I2RS 201 agent. 203 While at first glance this may seem equivalent to the writable- 204 running data store in NETCONF, running-config can be copied to a 205 persistent data store, like startup config. I2RS ephemeral state 206 MUST NOT be persisted. 208 3.2. Constraints 210 Ephemeral-REQ-02: Non-ephemeral state MUST NOT refer to ephemeral 211 state for constraint purposes; it SHALL be considered a validation 212 error if it does. 214 Ephemeral-REQ-03: Ephemeral state MUST be able to have constraints 215 that refer to operational state, this includes potentially fast 216 changing or short lived operational state nodes, such as MPLS LSP-ID 217 or a BGP IN-RIB. Ephemeral state constraints should be assessed when 218 the ephemeral state is written, and if any of the constraints change 219 to make the constraints invalid after that time the I2RS agent should 220 notify the I2RS Client. 222 Ephemeral-REQ-04: Ephemeral state MUST be able to refer to non- 223 ephemeral state as a constraint. Non-ephemeral state can be 224 configuration state or operational state. 226 Ephemeral-REQ-05: I2RS pub-sub, logging, RPC or other mechanisms may 227 lead to undesirable or unsustainable resource consumption on a system 228 implementing an I2RS Agent. It is RECOMMENDED that mechanisms be 229 made available to permit prioritization of I2RS operations, when 230 appropriate, to permit implementations to shed work load when 231 operating under constrained resources. An example of such a work 232 shedding mechanism is rate-limiting. 234 3.3. Hierarchy 236 Ephemeral-REQ-06: YANG MUST have the ability to: 238 1. to define a YANG module or submodule schema that only contains 239 data nodes with the property of being ephemeral, and 241 2. to augment a YANG data model with additional YANG schema nodes 242 that have the property of being ephemeral. 244 3.4. Ephemeral Configuration overlapping Local Configuration 246 Ephemeral-REQ-07: Local configuration MUST have a priority that is 247 comparable with individual I2RS client priorities for making changes. 248 This priority will determine whether local configuration changes or 249 individual ephemeral configuration changes take precedence as 250 described in RFC7921. The I2RS protocol MUST support his mechanism. 252 4. YANG Features for Ephemeral State 254 Ephemeral-REQ-08:In addition to config true/false, there MUST be a 255 way to indicate that YANG schema nodes represent ephemeral state. It 256 is desirable to allow for, and have to way to indicate, config false 257 YANG schema nodes that are writable operational state. 259 5. NETCONF Features for Ephemeral State 261 Ephemeral-REQ-09: The changes to NETCONF/RESTCONF must include: 263 1. Support for communication mechanisms to enable an I2RS client to 264 determine that an I2RS agent supports the mechanisms needed for 265 I2RS operation. 267 2. The ephemeral state MUST support notification of write conflicts 268 using the priority requirements defined in section 7 below in 269 requirements Ephemeral-REQ-11 through Ephemeral-REQ-14). 271 6. RESTCONF Features for Ephemeral State 273 Ephemeral-REQ-10: The conceptual changes to RESTCONF are: 275 1. Support for communication mechanisms to enable an I2RS client to 276 determine that an I2RS agent supports the mechanisms needed for 277 I2RS operation. 279 2. The ephemeral state must support notification of write conflicts 280 using the priority requirements defined in section 7 below in 281 requirements Ephemeral-REQ-11 through Ephemeral-REQ-14). 283 7. Requirements regarding Supporting Multi-Head Control via Client 284 Priority 286 To support Multi-Headed Control, I2RS requires that there be a 287 decidable means of arbitrating the correct state of data when 288 multiple clients attempt to manipulate the same piece of data. This 289 is done via a priority mechanism with the highest priority winning. 290 This priority is per-client. 292 Ephemeral-REQ-11: The I2RS Protocol (e.g. NETCONF/RESTCONF + yang) 293 MUST be able to support 295 o the data nodes MAY store I2RS client identity and not the 296 effective priority at the time the data node is stored. 298 o Per SEC-REQ-07 in section 3.1 of 299 [I-D.ietf-i2rs-protocol-security-requirements], an identifier MUST 300 have just one priority. The I2RS protocol MUST support the 301 ability to have data nodes MAY store I2RS client identity and not 302 the effective priority of the I2RS client at the time the data 303 node is stored. 305 o The priority MAY be dynamically changed by AAA, but the exact 306 actions are part of the protocol definition as long as collisions 307 are handled as described in Ephemeral-REQ-12, Ephemeral-REQ-13, 308 and Ephemeral-REQ-14. 310 Ephemeral-REQ-12: When a collision occurs as two clients are trying 311 to write the same data node, this collision is considered an error 312 and priorities were created to give a deterministic result. When 313 there is a collision, a notification (which includes indicating data 314 node the collision occurred on) MUST BE sent to the original client 315 to give the original client a chance to deal with the issues 316 surrounding the collision. The original client may need to fix their 317 state. 319 Note:RESTCONF and NETCONF posts can come in concurrently from 320 alternative sources (see ETag in [I-D.ietf-netconf-restconf] section 321 3.4.1.2 usage). Therefore the collision detection and comparison of 322 priority needs to occur both for both type of updates (POST or edit- 323 config) at the point of comparison. 325 Ephemeral-REQ-13: Multi-headed control is required for collisions and 326 the priority resolution of collisions. Multi-headed control is not 327 tied to ephemeral state. I2RS protocol MUST NOT mandate how AAA 328 supports priority. Mechanisms which prevent collisions of two 329 clients trying to modify the same node of data are the focus. 331 Ephemeral-REQ-14: A deterministic conflict resolution mechanism MUST 332 be provided to handle the error scenario that two clients, with the 333 same priority, update the same configuration data node. The I2RS 334 architecture gives one way that this could be achieved, by specifying 335 that the first update wins. Other solutions, that prevent 336 oscillation of the config data node, are also acceptable. 338 8. Multiple Message Transactions 340 Ephemeral-REQ-15: Section 7.9 of the [I-D.ietf-i2rs-architecture] 341 states the I2RS architecture does not include multi-message atomicity 342 and roll-back mechanisms. The I2RS protocol implementation MUST not 343 require the support of these features. As part of this requirement, 344 the I2SR protocol should support: 346 multiple operations in one or more messages handling can handle 347 errors within the set of operations in many ways. 349 No multi-message commands SHOULD cause errors to be inserted into 350 the I2RS ephemeral state. 352 9. Pub/Sub Requirements Expanded for Ephemeral State 354 I2RS clients require the ability to monitor changes to ephemeral 355 state. While subscriptions are well defined for receiving 356 notifications, the need to create a notification set for all 357 ephemeral configuration state may be overly burdensome to the user. 359 There is thus a need for a general subscription mechanism that can 360 provide notification of changed state, with sufficient information to 361 permit the client to retrieve the impacted nodes. This should be 362 doable without requiring the notifications to be created as part of 363 every single I2RS module. 365 The publication/subscription requirements for I2RS are in 366 [I-D.ietf-i2rs-pub-sub-requirements], and the following general 367 requirements SHOULD be understood to be expanded to to include 368 ephemeral state: 370 o Pub-Sub-REQ-01: The Subscription Service MUST support 371 subscriptions against ephemeral state in operational data stores, 372 configuration data stores or both. 374 o Pub-Sub-REQ-02: The Subscription Service MUST support filtering so 375 that subscribed updates under a target node might publish only 376 ephemeral state in operational data or configuration data, or 377 publish both ephemeral and operational data. 379 o Pub-Sub-REQ-03: The subscription service must support 380 subscriptions which are ephemeral. (E.g. An ephemeral data model 381 which has ephemeral subscriptions.) 383 10. IANA Considerations 385 There are no IANA requirements for this document. 387 11. Security Considerations 389 The security requirements for the I2RS protocol are covered in 390 [I-D.ietf-i2rs-protocol-security-requirements] document. The 391 security requirements for the I2RS protocol environment are in 392 [I-D.ietf-i2rs-security-environment-reqs]. 394 12. Acknowledgements 396 This document is an attempt to distill lengthy conversations on the 397 I2RS mailing list for an architecture that was for a long period of 398 time a moving target. Some individuals in particular warrant 399 specific mention for their extensive help in providing the basis for 400 this document: 402 o Alia Atlas 404 o Andy Bierman 406 o Martin Bjorklund 408 o Dean Bogdanavich 410 o Rex Fernando 412 o Joel Halpern 414 o Thomas Nadeau 416 o Juergen Schoenwaelder 418 o Kent Watsen 420 o Robert Wilton 422 13. References 423 13.1. Normative References: 425 [I-D.ietf-i2rs-architecture] 426 Atlas, A., Halpern, J., Hares, S., Ward, D., and T. 427 Nadeau, "An Architecture for the Interface to the Routing 428 System", draft-ietf-i2rs-architecture-15 (work in 429 progress), April 2016. 431 [I-D.ietf-i2rs-protocol-security-requirements] 432 Hares, S., Migault, D., and J. Halpern, "I2RS Security 433 Related Requirements", draft-ietf-i2rs-protocol-security- 434 requirements-06 (work in progress), May 2016. 436 [I-D.ietf-i2rs-pub-sub-requirements] 437 Voit, E., Clemm, A., and A. Prieto, "Requirements for 438 Subscription to YANG Datastores", draft-ietf-i2rs-pub-sub- 439 requirements-09 (work in progress), May 2016. 441 [I-D.ietf-i2rs-security-environment-reqs] 442 Migault, D., Halpern, J., and S. Hares, "I2RS Environment 443 Security Requirements", draft-ietf-i2rs-security- 444 environment-reqs-01 (work in progress), April 2016. 446 [I-D.ietf-i2rs-traceability] 447 Clarke, J., Salgueiro, G., and C. Pignataro, "Interface to 448 the Routing System (I2RS) Traceability: Framework and 449 Information Model", draft-ietf-i2rs-traceability-11 (work 450 in progress), May 2016. 452 [I-D.ietf-netconf-restconf] 453 Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 454 Protocol", draft-ietf-netconf-restconf-15 (work in 455 progress), July 2016. 457 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 458 and A. Bierman, Ed., "Network Configuration Protocol 459 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 460 . 462 13.2. Informative References 464 [I-D.hares-i2rs-protocol-strawman] 465 Hares, S. and a. amit.dass@ericsson.com, "I2RS protocol 466 strawman", draft-hares-i2rs-protocol-strawman-03 (work in 467 progress), July 2016. 469 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 470 Requirement Levels", BCP 14, RFC 2119, 471 DOI 10.17487/RFC2119, March 1997, 472 . 474 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 475 the Network Configuration Protocol (NETCONF)", RFC 6020, 476 DOI 10.17487/RFC6020, October 2010, 477 . 479 Authors' Addresses 481 Jeff Haas 482 Juniper 484 Email: jhaas@juniper.net 486 Susan Hares 487 Huawei 488 Saline 489 US 491 Email: shares@ndzh.com