idnits 2.17.1 draft-ietf-netmod-opstate-reqs-00.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 : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 19, 2015) is 3105 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NETMOD Working Group K. Watsen 3 Internet-Draft Juniper Networks 4 Intended status: Informational T. Nadeau 5 Expires: April 21, 2016 Brocade Networks 6 October 19, 2015 8 NETMOD Operational State Requirements 9 draft-ietf-netmod-opstate-reqs-00 11 Abstract 13 This document defines requirements for servers enabling better 14 visibility and control over the server's operational state. To 15 achieve this end, this document also defines terminology describing a 16 conceptual model enabling the requirements to be expressed. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on April 21, 2016. 35 Copyright Notice 37 Copyright (c) 2015 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 53 2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 3 54 3. Security Considerations . . . . . . . . . . . . . . . . . . . 5 55 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 56 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 57 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 58 6.1. Normative References . . . . . . . . . . . . . . . . . . 5 59 6.2. Informative References . . . . . . . . . . . . . . . . . 6 60 Appendix A. Relation to Terms Defined in Other Drafts . . . . . 7 61 Appendix B. Relation to Requirements in Other Drafts . . . . . . 7 62 Appendix C. Open Issues . . . . . . . . . . . . . . . . . . . . 7 64 1. Terminology 66 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 67 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 68 document are to be interpreted as described in RFC 2119 [RFC2119]. 70 The term "server" is used throughout this document to refer to what 71 is many times known as the "device", "system", or "network element". 72 This definition is intended to be consistent with the term "server" 73 defined in [RFC6241], Section 1.1, but free of any association to a 74 particular protocol. 76 This document defines the following terms: 78 Applied Configuration: This data represents the configuration state 79 that the server is actually in. That is, the configuration state 80 which is currently being used by server components (e.g., control 81 plane daemons, operating system kernels, line cards). 83 NOTE: The server's ability to report applied configuration 84 accurately may be limited in some cases, such as when the 85 configuration goes through an intermediate layer without an 86 ability to inspect the lower layer. 88 Asynchronous Configuration Operation: A configuration request to 89 update the running configuration of a server that is applied 90 asynchronously with respect to the client request. The server 91 MUST update its intended configuration (see term) before replying 92 to the client indicating whether the request will be processed. 93 This reply to the client only indicates whether there are any 94 errors in the original request. The server's applied 95 configuration state (see term) is updated after the configuration 96 change has been fully effected to all impacted components in the 97 server. Once applied, there MUST be a mechanism for the client 98 to determine when the request has completed processing and 99 whether the intended config is now fully effective or there are 100 any errors from applying the configuration change, which could be 101 from an asynchronous notification or via a client operation. 103 Continue On Error: Continue to process configuration data on error; 104 error is recorded, and negative response is generated if any 105 errors occur. 107 Derived State: This data represents information which is generated 108 as part of the server's own interactions. For example, derived 109 state may consist of the results of protocol interactions (the 110 negotiated duplex state of an Ethernet link), statistics (such as 111 message queue depth), or counters (such as packet input or output 112 bytes). 114 Intended Configuration: This data represents the configuration state 115 that the network operator intends the server to be in, and that 116 has been accepted by the server as valid configuration. 118 Rollback On Error: If an error condition occurs such that part of 119 applying the configuration fails, the server will stop processing 120 the configuration operation and restore the specified 121 configuration to its complete state at the start of this 122 configuration operation. 124 Synchronous Configuration Operation: A configuration request to 125 update the running configuration of a server that is applied 126 synchronously with respect to the client request (i.e. a blocking 127 call). The server MUST fully attempt to apply the configuration 128 change to all impacted components in the server, updating both 129 the server's intended and applied configuration (see terms), 130 before replying to the client. The reply to the client indicates 131 whether there are any errors in the request or errors from 132 applying the configuration change. 134 2. Requirements 136 1. Ability to interact with both intended and applied configuration 138 A. The ability to ask the operational components of a server 139 (e.g., line cards) for the configuration that they are 140 currently using. This is the applied configuration (see 141 term). 143 B. Applied configuration is read-only 144 C. The data model for the applied configuration is the same as 145 the data model for the intended configuration (same leaves) 147 D. When a configuration change for any intended configuration 148 node has been successfully applied to the server (e.g. not 149 failed, nor deferred due to absent hardware) then the 150 existence and value of the corresponding applied 151 configuration node must match the intended configuration 152 node. 154 2. Applied configuration as part of operational state 156 A. The ability to retrieve the applied configuration and derived 157 state nodes in a single protocol operation. 159 3. Support for both synchronous and asynchronous configuration 160 operations (see terms) 162 A. A server may support only synchronous configuration 163 operations, or only asynchronous configuration operations, or 164 both synchronous and asynchronous configuration operations on 165 a client-specified per-operation basis. 167 B. Servers that support asynchronous configuration operations 168 MAY also provide a verify operation that a client can request 169 from the server to return information regarding the 170 difference between the intended and applied configurations. 172 C. The configuration protocol MUST specify how configuration 173 errors are handled. Errors may be handled by "stop on 174 error", "continue on error" or "rollback on error" semantics 175 (see terms). Support for "rollback on error" SHOULD be 176 provided. 178 4. Separation of configuration and operational state data; ability 179 to retrieve them and independently 181 A. Be able to retrieve only the derived state aspects of 182 operational state 184 B. Be able to retrieve only the non-derived state aspects of 185 operational state 187 C. Be able to retrieve both the derived and non-derived state 188 aspects of operational state together 190 5. Ability to retrieve operational state corresponding only to 191 derived values, statistics, etc. 193 // this is a duplicate of # 4-a 195 6. Ability to relate configuration with its corresponding 196 operational state 198 A. Ability to map intended config nodes to corresponding applied 199 config nodes 201 B. Ability to map intended config nodes to associated derived 202 state nodes 204 C. The mappings needs to be programmatically consumable 206 7. Ability for distinct modules to leverage a common model-structure 208 A. Focus on the IETF-defined modules, and ideally provides 209 guidance to other SDOs 211 B. Multiple domain-specific model-structure trees are okay 213 C. Model-structures may be defined in multiple modules with 214 distinct namespaces 216 3. Security Considerations 218 None 220 4. IANA Considerations 222 None 224 5. Acknowledgements 226 The authors would like to thank the following for contributing to 227 this document (in alphabetic order): Acee Lindem, Andy Bierman, Anees 228 Shaikh, Benoit Claise, Carl Moberg, Dan Romascanu, Dean Bogdanovic, 229 Gert Grammel, Jonathan Hansford, Juergen Schoenwaelder, Lou Berger, 230 Mahesh Jethanandani, Martin Bjorklund, Phil Shafer, Randy Presuhn, 231 Rob Shakir, Robert Wilton, Sterne, Jason. 233 6. References 235 6.1. Normative References 237 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 238 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 239 RFC2119, March 1997, 240 . 242 6.2. Informative References 244 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 245 and A. Bierman, Ed., "Network Configuration Protocol 246 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 247 . 249 [draft-openconfig-netmod-model-structure-00] 250 Shaikh, A., Shakir, R., D'Souza, K., and L. Fang, 251 "Operational Structure and Organization of YANG Models", 252 draft-openconfig-netmod-model-structure-00 (work in 253 progress), 2015, . 256 [draft-openconfig-netmod-opstate-01] 257 Shakir, R., Shaikh, A., and M. Hines, "Consistent Modeling 258 of Operational State Data in YANG", draft-openconfig- 259 netmod-opstate-01 (work in progress), 2015, 260 . 263 Appendix A. Relation to Terms Defined in Other Drafts 265 The following terms were originally defined in [RFC6241], but since 266 modified by the NETMOD WG: 268 o continue-on-error 270 o stop-on-error 272 o rollback-on-error 274 The following terms were originally defined in 275 [draft-openconfig-netmod-opstate-01], but since modified by the 276 NETMOD WG: 278 o Intended Configuration 280 o Applied Configuration 282 o Derived State 284 Appendix B. Relation to Requirements in Other Drafts 286 The requirements in this document roughly map onto the requirements 287 listed in [draft-openconfig-netmod-opstate-01] and 288 [draft-openconfig-netmod-model-structure-00] as list below. Some 289 liberty was taken to adjust the requirements based on what looked 290 liked consensus from on list discussions: 292 1. draft-openconfig-netmod-opstate-01, Section 3 294 2. draft-openconfig-netmod-opstate-01, Section 4.1 296 3. draft-openconfig-netmod-opstate-01, Section 4.2 298 4. draft-openconfig-netmod-opstate-01, Section 4.3 300 5. draft-openconfig-netmod-opstate-01, Section 4.4 302 6. draft-openconfig-netmod-opstate-01, Section 4.5 304 7. draft-openconfig-netmod-model-structure-00 (no section) 306 Appendix C. Open Issues 308 All issues with this draft are tracked using GitHub issues. Please 309 see: https://github.com/netmod-wg/opstate-reqs/issues to see 310 currently opened issues. 312 Authors' Addresses 314 Kent Watsen 315 Juniper Networks 317 EMail: kwatsen@juniper.net 319 Thomas Nadeau 320 Brocade Networks 322 EMail: tnadeau@lucidvision.com