idnits 2.17.1 draft-ietf-i2rs-ephemeral-state-11.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 (June 25, 2016) is 2859 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 388, but not defined == Missing Reference: 'RFC6241' is mentioned on line 456, but not defined == Missing Reference: 'I-D.ietf-netconf-restconf' is mentioned on line 420, but not defined == Missing Reference: 'I-D.ietf-i2rs-pub-sub-requirements' is mentioned on line 399, but not defined == Missing Reference: 'I-D.ietf-i2rs-protocol-security-requirements' is mentioned on line 394, but not defined == Missing Reference: 'I-D.ietf-i2rs-security-environment-reqs' is mentioned on line 404, but not defined == Missing Reference: 'I-D.ietf-i2rs-traceability' is mentioned on line 409, but not defined == Missing Reference: 'I-D.ietf-netconf-call-home' is mentioned on line 415, but not defined == Missing Reference: 'I-D.ietf-netconf-server-model' is mentioned on line 425, but not defined == Missing Reference: 'I-D.ietf-netconf-yang-library' is mentioned on line 430, but not defined == Missing Reference: 'I-D.ietf-netconf-yang-patch' is mentioned on line 435, but not defined == Missing Reference: 'I-D.ietf-netconf-yang-push' is mentioned on line 440, but not defined == Missing Reference: 'I-D.ietf-netconf-zerotouch' is mentioned on line 446, but not defined == Missing Reference: 'I-D.ietf-netmod-yang-metadata' is mentioned on line 451, but not defined == Unused Reference: 'I-D.hares-i2rs-protocol-strawman' is defined on line 463, but no explicit reference was found in the text == Unused Reference: 'RFC6536' is defined on line 478, but no explicit reference was found in the text == Outdated reference: A later version (-03) exists of draft-hares-i2rs-protocol-strawman-02 -- Obsolete informational reference (is this intentional?): RFC 6536 (Obsoleted by RFC 8341) Summary: 0 errors (**), 0 flaws (~~), 18 warnings (==), 2 comments (--). 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: December 27, 2016 Huawei 6 June 25, 2016 8 I2RS Ephemeral State Requirements 9 draft-ietf-i2rs-ephemeral-state-11 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 December 27, 2016. 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 . . . . . . . . . . . . . . . . . . . . . . . . 5 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 . . . . . . . . . . . . . . . . . . . . . . . 6 64 8. Multiple Message Transactions . . . . . . . . . . . . . . . . 7 65 9. Pub/Sub Requirements Expanded for Ephemeral State . . . . . . 7 66 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 67 11. Security Considerations . . . . . . . . . . . . . . . . . . . 8 68 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 69 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 70 13.1. Normative References: . . . . . . . . . . . . . . . . . 9 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 as ideas for the NETCONF, RESTCONF, and 103 YANG changes. 105 The purpose of these requirements and the suggested protocol straw 106 man is to provide a quick turnaround on creating the I2RS protocol. 108 Support for ephemeral state is I2RS protocol requirement that 109 requires datastore changes (see section 3), Yang additions (see 110 section 4), NETCONF additions (see section 5), and RESTCONF additions 111 (see section 6). 113 Sections 7-9 provide details that expand upon the changes in sections 114 3-6 to clarify requirements discussed by the I2RS and NETCONF working 115 groups. Sections 7 provide additional requirements that detail how 116 write-conflicts should be resolved if two I2RS client write the same 117 data. Section 8 provides an additional requirement that details on 118 I2RS support of multiple message transactions. Section 9 highlights 119 two requirements in the I2RS publication/subscription requirements 120 [I-D.ietf-i2rs-pub-sub-requirements] that must be expanded for 121 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 ten requirements that 133 [I-D.ietf-i2rs-architecture] contains which provide context for the 134 ephemeral data state requirements given in sections 3-8: 136 1. The I2RS protocol SHOULD support highly reliable notifications 137 (but not perfectly reliable notifications) from an I2RS agent to 138 an I2RS client. 140 2. The I2RS protocol SHOULD support a high bandwidth, asynchronous 141 interface, with real-time guarantees on getting data from an 142 I2RS agent by an I2RS client. 144 3. The I2RS protocol will operate on data models which MAY be 145 protocol independent or protocol dependent. 147 4. I2RS Agent MUST record the client identity when a node is 148 created or modified. The I2RS Agent SHOULD to be able to read 149 the client identity of a node and use the client identity's 150 associated priority to resolve conflicts. The secondary 151 identity is useful for traceability and may also be recorded. 153 5. Client identity MUST have only one priority for the client's 154 identifier. A collision on writes is considered an error, but 155 the priority associated with each client identifier is utilized 156 to compare requests from two different clients in order to 157 modify an existing node entry. Only an entry from a client 158 which is higher priority can modify an existing entry (First 159 entry wins). Priority only has meaning at the time of use. 161 6. The Agent identity and the Client identity SHOULD be passed 162 outside of the I2RS protocol in a authentication and 163 authorization protocol (AAA). Client priority may be passed in 164 the AAA protocol. The values of identities are originally set 165 by operators, and not standardized. 167 7. An I2RS Client and I2RS Agent MUST mutually authenticate each 168 other based on pre-established authenticated identities. 170 8. Secondary identity data is read-only meta-data that is recorded 171 by the I2RS agent associated with a data model's node is 172 written, updated or deleted. Just like the primary identity, 173 the secondary identity SHOULD only be recorded when the data 174 node is written or updated or deleted 176 9. I2RS agent MAY have a lower priority I2RS client attempting to 177 modify a higher priority client's entry in a data model. The 178 filtering out of lower priority clients attempting to write or 179 modify a higher priority client's entry in a data model SHOULD 180 be effectively handled and not put an undue strain on the I2RS 181 agent. 183 10. The I2RS protocol MUST support the use of a secure transport. 184 However, certain functions such as notifications MAY use a non- 185 secure transport. Each model or service (notification, logging) 186 must define within the model or service the valid uses of a non- 187 secure transport. 189 3. Ephemeral State Requirements 191 In requirements Ephemeral-REQ-01 to Ephemeral-05, Ephemeral state is 192 defined as potentially including both ephemeral configured state and 193 operational state. 195 3.1. Persistence 197 Ephemeral-REQ-01: I2RS requires ephemeral state; i.e. state that does 198 not persist across reboots. If state must be restored, it should be 199 done solely by replay actions from the I2RS client via the I2RS 200 agent. 202 While at first glance this may seem equivalent to the writable- 203 running data store in NETCONF, running-config can be copied to a 204 persistent data store, like startup config. I2RS ephemeral state 205 MUST NOT be persisted. 207 3.2. Constraints 209 Ephemeral-REQ-02: Non-ephemeral state MUST NOT refer to ephemeral 210 state for constraint purposes; it SHALL be considered a validation 211 error if it does. 213 Ephemeral-REQ-03: Ephemeral state may have constraints that refer to 214 operational state, this includes potentially fast changing or short 215 lived operational state nodes, such as MPLS LSP-ID or a BGP IN-RIB. 217 Ephemeral-REQ-04: Ephemeral state MUST be able to refer to non- 218 ephemeral state as a constraint. 220 Ephemeral-REQ-05: I2RS pub-sub, logging, RPC or other mechanisms may 221 lead to undesirable or unsustainable resource consumption on a system 222 implementing an I2RS Agent. It is RECOMMENDED that mechanisms be 223 made available to permit prioritization of I2RS operations, when 224 appropriate, to permit implementations to shed work load when 225 operating under constrained resources. An example of such a work 226 shedding mechanism is rate-limiting. 228 3.3. Hierarchy 230 Ephemeral-REQ-06: The ability to augment Yang schema nodes with 231 additional Yang Schema nodes that have the property of being 232 ephemeral. 234 3.4. Ephemeral Configuration overlapping Local Configuration 236 Ephemeral-REQ-07: Ephemeral configuration state could override 237 overlapping local configuration state, or vice-versa. 238 Implementations MUST provide a mechanism to choose which takes 239 precedence. This mechanism MUST include local configuration (policy) 240 and MAY be provided via the I2RS protocol mechanisms. 242 4. YANG Features for Ephemeral State 244 Ephemeral-REQ-08: Yang MUST have a way to indicate in a data model 245 that schema nodes have the following properties: ephemeral, writable/ 246 not-writable, and status/configuration. 248 5. NETCONF Features for Ephemeral State 250 Ephemeral-REQ-09: The conceptual changes to NETCONF 252 1. Support for communication mechanisms to enable an I2RS client to 253 determine that an I2RS agent supports the mechanisms needed for 254 I2RS operation. 256 2. The ephemeral state must support notification of write conflicts 257 using the priority requirements defined in section 7 below in 258 requirements Ephemeral-REQ-11 through Ephemeral-REQ-14). 260 6. RESTCONF Features for Ephemeral State 262 Ephemeral-REQ-10: The conceptual changes to RESTCONF are: 264 1. Support for communication mechanisms to enable an I2RS client to 265 determine that an I2RS agent supports the mechanisms needed for 266 I2RS operation. 268 2. The ephemeral state must support notification of write conflicts 269 using the priority requirements defined in section 7 below in 270 requirements Ephemeral-REQ-11 through Ephemeral-REQ-14). 272 7. Requirements regarding Supporting Multi-Head Control via Client 273 Priority 275 To support Multi-Headed Control, I2RS requires that there be a 276 decidable means of arbitrating the correct state of data when 277 multiple clients attempt to manipulate the same piece of data. This 278 is done via a priority mechanism with the highest priority winning. 279 This priority is per-client. 281 Ephemeral-REQ-11: The data nodes MAY store I2RS client identity and 282 not the effective priority at the time the data node is stored. Per 283 SEC-REQ-07 in section 3.1 of 284 [I-D.ietf-i2rs-protocol-security-requirements], an identifier must 285 have just one priority. Therefore, the data nodes MAY store I2RS 286 client identity and not the effective priority of the I2RS client at 287 the time the data node is stored. The priority MAY be dynamically 288 changed by AAA, but the exact actions are part of the protocol 289 definition as long as collisions are handled as described in 290 Ephemeral-REQ-12, Ephemeral-REQ-13, and Ephemeral-REQ-14. 292 Ephemeral-REQ-12: When a collision occurs as two clients are trying 293 to write the same data node, this collision is considered an error 294 and priorities were created to give a deterministic result. When 295 there is a collision, a notification MUST BE sent to the original 296 client to give the original client a chance to deal with the issues 297 surrounding the collision. The original client may need to fix their 298 state. 300 Ephemeral-REQ-13: The requirement to support multi-headed control is 301 required for collisions and the priority resolution of collisions. 302 Multi-headed control is not tied to ephemeral state. I2RS is not 303 mandating how AAA supports priority. Mechanisms which prevent 304 collisions of two clients trying the same node of data are the focus. 306 Ephemeral-REQ-14: If two clients have the same priority, the 307 architecture says the first one wins. The I2RS protocol has this 308 requirement to prevent oscillations between clients. If one uses the 309 last wins scenario, you may oscillate. That was our opinion, but a 310 design which prevents oscillation is the key point. 312 8. Multiple Message Transactions 314 Ephemeral-REQ-15: Section 7.9 of the [I-D.ietf-i2rs-architecture] 315 states the I2RS architecture does not include multi-message atomicity 316 and roll-back mechanisms. I2RS notes multiple operations in one or 317 more messages handling can handle errors within the set of operations 318 in many ways. No multi-message commands SHOULD cause errors to be 319 inserted into the I2RS ephemeral data-store. 321 9. Pub/Sub Requirements Expanded for Ephemeral State 323 I2RS clients require the ability to monitor changes to ephemeral 324 state. While subscriptions are well defined for receiving 325 notifications, the need to create a notification set for all 326 ephemeral configuration state may be overly burdensome to the user. 328 There is thus a need for a general subscription mechanism that can 329 provide notification of changed state, with sufficient information to 330 permit the client to retrieve the impacted nodes. This should be 331 doable without requiring the notifications to be created as part of 332 every single I2RS module. 334 The publication/subscription requirements for I2RS are in 335 [I-D.ietf-i2rs-pub-sub-requirements], and the following general 336 requirements SHOULD be understood to be expanded to to include 337 ephemeral state: 339 o Pub-Sub-REQ-01: The Subscription Service MUST support 340 subscriptions against ephemeral data in operational data stores, 341 configuration data stores or both. 343 o Pub-Sub-REQ-02: The Subscription Service MUST support filtering so 344 that subscribed updates under a target node might publish only 345 ephemeral data in operational data or configuration data, or 346 publish both ephemeral and operational data. 348 10. IANA Considerations 350 There are no IANA requirements for this document. 352 11. Security Considerations 354 The security requirements for the I2RS protocol are covered in 355 [I-D.ietf-i2rs-protocol-security-requirements] document. The 356 security requirements for the I2RS protocol environment are in 357 [I-D.ietf-i2rs-security-environment-reqs]. 359 12. Acknowledgements 361 This document is an attempt to distill lengthy conversations on the 362 I2RS mailing list for an architecture that was for a long period of 363 time a moving target. Some individuals in particular warrant 364 specific mention for their extensive help in providing the basis for 365 this document: 367 o Alia Atlas 369 o Andy Bierman 371 o Martin Bjorklund 373 o Dean Bogdanavich 375 o Rex Fernando 376 o Joel Halpern 378 o Thomas Nadeau 380 o Juergen Schoenwaelder 382 o Kent Watsen 384 13. References 386 13.1. Normative References: 388 [I-D.ietf-i2rs-architecture] 389 Atlas, A., Halpern, J., Hares, S., Ward, D., and T. 390 Nadeau, "An Architecture for the Interface to the Routing 391 System", draft-ietf-i2rs-architecture-15 (work in 392 progress), April 2016. 394 [I-D.ietf-i2rs-protocol-security-requirements] 395 Hares, S., Migault, D., and J. Halpern, "I2RS Security 396 Related Requirements", draft-ietf-i2rs-protocol-security- 397 requirements-06 (work in progress), May 2016. 399 [I-D.ietf-i2rs-pub-sub-requirements] 400 Voit, E., Clemm, A., and A. Prieto, "Requirements for 401 Subscription to YANG Datastores", draft-ietf-i2rs-pub-sub- 402 requirements-09 (work in progress), May 2016. 404 [I-D.ietf-i2rs-security-environment-reqs] 405 Migault, D., Halpern, J., and S. Hares, "I2RS Environment 406 Security Requirements", draft-ietf-i2rs-security- 407 environment-reqs-01 (work in progress), April 2016. 409 [I-D.ietf-i2rs-traceability] 410 Clarke, J., Salgueiro, G., and C. Pignataro, "Interface to 411 the Routing System (I2RS) Traceability: Framework and 412 Information Model", draft-ietf-i2rs-traceability-11 (work 413 in progress), May 2016. 415 [I-D.ietf-netconf-call-home] 416 Watsen, K., "NETCONF Call Home and RESTCONF Call Home", 417 draft-ietf-netconf-call-home-17 (work in progress), 418 December 2015. 420 [I-D.ietf-netconf-restconf] 421 Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 422 Protocol", draft-ietf-netconf-restconf-13 (work in 423 progress), April 2016. 425 [I-D.ietf-netconf-server-model] 426 Watsen, K. and J. Schoenwaelder, "NETCONF Server and 427 RESTCONF Server Configuration Models", draft-ietf-netconf- 428 server-model-09 (work in progress), March 2016. 430 [I-D.ietf-netconf-yang-library] 431 Bierman, A., Bjorklund, M., and K. Watsen, "YANG Module 432 Library", draft-ietf-netconf-yang-library-06 (work in 433 progress), April 2016. 435 [I-D.ietf-netconf-yang-patch] 436 Bierman, A., Bjorklund, M., and K. Watsen, "YANG Patch 437 Media Type", draft-ietf-netconf-yang-patch-08 (work in 438 progress), March 2016. 440 [I-D.ietf-netconf-yang-push] 441 Clemm, A., Prieto, A., Voit, E., Tripathy, A., and E. 442 Nilsen-Nygaard, "Subscribing to YANG datastore push 443 updates", draft-ietf-netconf-yang-push-03 (work in 444 progress), June 2016. 446 [I-D.ietf-netconf-zerotouch] 447 Watsen, K. and M. Abrahamsson, "Zero Touch Provisioning 448 for NETCONF or RESTCONF based Management", draft-ietf- 449 netconf-zerotouch-08 (work in progress), April 2016. 451 [I-D.ietf-netmod-yang-metadata] 452 Lhotka, L., "Defining and Using Metadata with YANG", 453 draft-ietf-netmod-yang-metadata-07 (work in progress), 454 March 2016. 456 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 457 and A. Bierman, Ed., "Network Configuration Protocol 458 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 459 . 461 13.2. Informative References 463 [I-D.hares-i2rs-protocol-strawman] 464 Hares, S., Bierman, A., and a. amit.dass@ericsson.com, 465 "I2RS protocol strawman", draft-hares-i2rs-protocol- 466 strawman-02 (work in progress), May 2016. 468 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 469 Requirement Levels", BCP 14, RFC 2119, 470 DOI 10.17487/RFC2119, March 1997, 471 . 473 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 474 the Network Configuration Protocol (NETCONF)", RFC 6020, 475 DOI 10.17487/RFC6020, October 2010, 476 . 478 [RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration 479 Protocol (NETCONF) Access Control Model", RFC 6536, 480 DOI 10.17487/RFC6536, March 2012, 481 . 483 Authors' Addresses 485 Jeff Haas 486 Juniper 488 Email: jhaas@juniper.net 490 Susan Hares 491 Huawei 492 Saline 493 US 495 Email: shares@ndzh.com