idnits 2.17.1 draft-ietf-netmod-opstate-reqs-03.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: ---------------------------------------------------------------------------- == It seems as if not all pages are separated by form feeds - found 6 form feeds but 15 pages 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 (January 8, 2016) is 3030 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 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: July 11, 2016 Brocade Networks 6 January 8, 2016 8 Terminology and Requirements for Enhanced Handling of Operational State 9 draft-ietf-netmod-opstate-reqs-03 11 Abstract 13 This document primarily regards the difference between the intended 14 configuration and the applied configuration of a device and how 15 intended and applied configuration relate to the operational state of 16 a device. This document defines requirements for the applied 17 configuration's data model and its values, as well as for enabling a 18 client to know when a configuration has been fully applied or not, 19 how to access operational state, and how to relate intended 20 configuration nodes to applied configuration and derived state nodes. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on July 11, 2016. 39 Copyright Notice 41 Copyright (c) 2016 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 58 3. Backwards Compatibility . . . . . . . . . . . . . . . . . . . 4 59 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 4 60 5. Security Considerations . . . . . . . . . . . . . . . . . . . 5 61 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 62 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 63 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 64 8.1. Normative References . . . . . . . . . . . . . . . . . . 6 65 8.2. Informative References . . . . . . . . . . . . . . . . . 6 66 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 68 1. Introduction 70 This document primarily regards the difference between the intended 71 configuration and the applied configuration of a device and how 72 intended and applied configuration relate to the operational state of 73 a device. This document defines requirements for the applied 74 configuration's data model and its values, as well as for enabling a 75 client to know when a configuration has been fully applied or not, 76 how to access operational state, and how to relate intended 77 configuration nodes to applied configuration and derived state nodes. 79 2. Terminology 81 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 82 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 83 document are to be interpreted as described in RFC 2119 [RFC2119]. 85 The term "client" is used throughout this document to refer to what 86 is many times known as the "application" or "network management 87 system". This definition is intended to be consistent with the term 88 "client" defined in [RFC6241], Section 1.1, but independent of any 89 association to a particular protocol. 91 The term "server" is used throughout this document to refer to what 92 is many times known as the "device", "system", or "network element". 93 This definition is intended to be consistent with the term "server" 94 defined in [RFC6241], Section 1.1, but independent of any association 95 to a particular protocol. 97 This document defines the following terms: 99 Applied Configuration: This data represents the configuration state 100 that the server is actually in. That is, the configuration state 101 which is currently being used by server components (e.g., control 102 plane daemons, operating system kernels, line cards). With 103 respect to NETCONF architecture, the applied configuration 104 of [RFC6244] 106 NOTE: The server's ability to report applied configuration 107 accurately may be limited in some cases, such as when the 108 configuration goes through an intermediate layer without an 109 ability to inspect the lower layer. 111 Asynchronous Configuration Operation: A configuration request to 112 update the running configuration of a server that is applied 113 asynchronously with respect to the client request. The server 114 MUST update its intended configuration (see term) before replying 115 to the client indicating whether the request will be processed. 116 This reply to the client only indicates whether there are any 117 errors in the original request. The server's applied 118 configuration state (see term) is updated after the configuration 119 change has been fully effected to all impacted components in the 120 server. Once applied, there MUST be a mechanism for the client 121 to determine when the request has completed processing and 122 whether the intended config is now fully effective or there are 123 any errors from applying the configuration change, which could be 124 from an asynchronous notification or via a client operation. 126 Derived State: This data represents information which is generated 127 as part of the server's own interactions. For example, derived 128 state may consist of the results of protocol interactions (the 129 negotiated duplex state of an Ethernet link), statistics (such as 130 message queue depth), or counters (such as packet input or output 131 bytes). 133 Intended Configuration: This data represents the configuration state 134 that the network operator intends the server to be in, and that 135 has been accepted by the server as valid configuration. With 136 respect to NETCONF architecture, the intended configuration is 137 captured by the "config database" box listed on page 15 of 138 [RFC6244] 140 Operational State: Operational State is the current state of the 141 system as known to the various components of the system (e.g., 142 control plane daemons, operating system kernels, line cards). 144 The operational state includes both applied configuration and 145 derived state. 147 Synchronous Configuration Operation: A configuration request to 148 update the running configuration of a server that is applied 149 synchronously with respect to the client request (i.e. a blocking 150 call). The server MUST fully attempt to apply the configuration 151 change to all impacted components in the server, updating both 152 the server's intended and applied configuration (see terms), 153 before replying to the client. The reply to the client indicates 154 whether there are any errors in the request or errors from 155 applying the configuration change. 157 3. Backwards Compatibility 159 Any solution satisfying the requirements specified in this document 160 MUST ensure backwards compatibility with regards to existing 161 deployments. Specifically, it MUST be possible to upgrade a server 162 to one that supports the solution without breaking existing/legacy 163 clients. Likewise, it MUST be possible for a client that has been 164 coded to support the solution to interoperate appropriately with 165 existing/legacy servers. 167 4. Requirements 169 1. Ability to interact with both intended and applied configuration 171 A. The ability to ask the operational components of a server 172 (e.g., line cards) for the configuration that they are 173 currently using. This is the applied configuration (see 174 term). 176 B. Applied configuration is read-only 178 C. The data model for the applied configuration is the same as 179 the data model for the intended configuration (same leaves) 181 D. When a configuration change for any intended configuration 182 node has been successfully applied to the server (e.g. not 183 failed, nor deferred due to absent hardware) then the 184 existence and value of the corresponding applied 185 configuration node must match the intended configuration 186 node. 188 2. Support for both synchronous and asynchronous configuration 189 operations (see terms) 190 A. A server may support only synchronous configuration 191 operations, or only asynchronous configuration operations, or 192 both synchronous and asynchronous configuration operations on 193 a client-specified per-operation basis. 195 B. Servers that support asynchronous configuration operations 196 MAY also provide a verify operation that a client can request 197 from the server to return information regarding the 198 difference between the intended and applied configurations. 200 C. The configuration protocol MUST specify how configuration 201 errors are handled. Errors MAY be handled by semantics 202 similar to NETCONF's error-options for the 203 operation (stop-on-error, continue-on-error, rollback-on- 204 error), as described in Section 7.2 in [RFC6241], but 205 extended to incorporate both the intended and applied 206 configurations. Support for "rollback on error" semantics 207 SHOULD be provided. 209 3. Separation of the applied configuration and derived state aspects 210 of operational state; ability to retrieve them independently and 211 together 213 A. Be able to retrieve only the applied configuration aspects of 214 operational state 216 B. Be able to retrieve only the derived state aspects of 217 operational state 219 C. Be able to retrieve both the applied configuration and 220 derived state aspects of operational state together 222 4. Ability to relate configuration with its corresponding 223 operational state 225 A. Ability to map intended config nodes to corresponding applied 226 config nodes 228 B. Ability to map intended config nodes to associated derived 229 state nodes 231 C. The mappings needs to be programmatically consumable 233 5. Security Considerations 235 It is understood that the intended and applied configurations will 236 differ while synchronization is in progress. During the 237 synchronization process, the server will be in an inconsistent state 238 from the client's perspective. Implementations need to take care to 239 ensure that this process minimizes gaps in the application of 240 security policy (e.g., replacing a firewall policy in a single step). 241 Implementations additionally need to ensure that any gaps in security 242 policies are not dependent on external input that an attacker might 243 be able to control or prevent access to. 245 6. IANA Considerations 247 None 249 7. Acknowledgements 251 The authors would like to thank the following for contributing to 252 this document (in alphabetic order): Acee Lindem, Andy Bierman, Anees 253 Shaikh, Benoit Claise, Carl Moberg, Dan Romascanu, Dean Bogdanovic, 254 Gert Grammel, Jason Sterne, Jonathan Hansford, Juergen Schoenwaelder, 255 Lou Berger, Mahesh Jethanandani, Martin Bjorklund, Phil Shafer, Randy 256 Presuhn, Rob Shakir, Robert Wilton. 258 8. References 260 8.1. Normative References 262 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 263 Requirement Levels", BCP 14, RFC 2119, 264 DOI 10.17487/RFC2119, March 1997, 265 . 267 8.2. Informative References 269 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 270 and A. Bierman, Ed., "Network Configuration Protocol 271 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 272 . 274 [RFC6244] Shafer, P., "An Architecture for Network Management Using 275 NETCONF and YANG", RFC 6244, DOI 10.17487/RFC6244, June 276 2011, . 278 Authors' Addresses 280 Kent Watsen 281 Juniper Networks 283 EMail: kwatsen@juniper.net 284 Thomas Nadeau 285 Brocade Networks 287 EMail: tnadeau@lucidvision.com