idnits 2.17.1 draft-ietf-netmod-opstate-reqs-04.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 5 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 22, 2016) is 3010 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 25, 2016 Brocade Networks 6 January 22, 2016 8 Terminology and Requirements for Enhanced Handling of Operational State 9 draft-ietf-netmod-opstate-reqs-04 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 25, 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. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 4 59 4. Security Considerations . . . . . . . . . . . . . . . . . . . 5 60 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 61 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 62 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 63 7.1. Normative References . . . . . . . . . . . . . . . . . . 6 64 7.2. Informative References . . . . . . . . . . . . . . . . . 6 65 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 67 1. Introduction 69 This document primarily regards the difference between the intended 70 configuration and the applied configuration of a device and how 71 intended and applied configuration relate to the operational state of 72 a device. This document defines requirements for the applied 73 configuration's data model and its values, as well as for enabling a 74 client to know when a configuration has been fully applied or not, 75 how to access operational state, and how to relate intended 76 configuration nodes to applied configuration and derived state nodes. 78 2. Terminology 80 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 81 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 82 document are to be interpreted as described in RFC 2119 [RFC2119]. 84 The term "client" is used throughout this document to refer to what 85 is many times known as the "application" or "network management 86 system". This definition is intended to be consistent with the term 87 "client" defined in [RFC6241], Section 1.1, but independent of any 88 association to a particular protocol. 90 The term "server" is used throughout this document to refer to what 91 is many times known as the "device", "system", or "network element". 92 This definition is intended to be consistent with the term "server" 93 defined in [RFC6241], Section 1.1, but independent of any association 94 to a particular protocol. 96 This document defines the following terms: 98 Applied Configuration: This data represents the configuration state 99 that the server is actually in. That is, the configuration state 100 which is currently being used by server components (e.g., control 101 plane daemons, operating system kernels, line cards). With 102 respect to NETCONF architecture, the applied configuration 103 of [RFC6244] 105 NOTE: The server's ability to report applied configuration 106 accurately may be limited in some cases, such as when the 107 configuration goes through an intermediate layer without an 108 ability to inspect the lower layer. 110 Asynchronous Configuration Operation: A configuration request to 111 update the running configuration of a server that is applied 112 asynchronously with respect to the client request. The server 113 MUST update its intended configuration before replying to the 114 client indicating whether the request will be processed. This 115 reply to the client only indicates whether there are any errors 116 in the original request. The server's applied configuration 117 state is updated after the configuration change has been fully 118 effected to all impacted components in the server. 120 Derived State: This data represents information which is generated 121 as part of the server's own interactions. For example, derived 122 state may consist of the results of protocol interactions (the 123 negotiated duplex state of an Ethernet link), statistics (such as 124 message queue depth), or counters (such as packet input or output 125 bytes). 127 Intended Configuration: This data represents the configuration state 128 that the network operator intends the server to be in, and that 129 has been accepted by the server as valid configuration. With 130 respect to NETCONF architecture, the intended configuration is 131 captured by the "config database" box listed on page 15 of 132 [RFC6244] 134 Operational State: Operational State is the current state of the 135 system as known to the various components of the system (e.g., 136 control plane daemons, operating system kernels, line cards). 137 The operational state includes both applied configuration and 138 derived state. 140 Synchronous Configuration Operation: A configuration request to 141 update the running configuration of a server that is applied 142 synchronously with respect to the client request (i.e. a blocking 143 call). The server MUST fully attempt to apply the configuration 144 change to all impacted components in the server, updating both 145 the server's intended and applied configuration, before replying 146 to the client. The reply to the client indicates whether there 147 are any errors in the request or errors from applying the 148 configuration change. 150 3. Requirements 152 1. Ability to interact with both intended and applied configuration 154 A. The ability to ask the operational components of a server 155 (e.g., line cards) for the configuration that they are 156 currently using. This is the applied configuration. 158 B. Applied configuration is read-only 160 C. The data model for the applied configuration is the same as 161 the data model for the intended configuration (same leaves) 163 D. When a configuration change for any intended configuration 164 node has been successfully applied to the server (e.g. not 165 failed, nor deferred due to absent hardware) then the 166 existence and value of the corresponding applied 167 configuration node must match the intended configuration 168 node. 170 2. Support for both synchronous and asynchronous configuration 171 operations 173 A. A server MUST support only synchronous configuration 174 operations, or only asynchronous configuration operations, or 175 both synchronous and asynchronous configuration operations on 176 a client-specified per-operation basis. 178 B. Servers that support asynchronous configuration operations 179 MUST provide a mechanism to notify the client when a request 180 has completed processing. The notification MUST indicate 181 whether the intended config is now fully applied or if there 182 were any errors from applying the configuration change. 184 C. Servers that support asynchronous configuration operations 185 SHOULD also provide a verify operation that a client can 186 request from the server to return information regarding the 187 difference between the intended and applied configurations. 189 D. The configuration protocol MUST specify how configuration 190 errors are handled. Errors SHOULD be handled by semantics 191 similar to NETCONF's error-options for the 192 operation (stop-on-error, continue-on-error, rollback-on- 193 error), as described in Section 7.2 in [RFC6241], but 194 extended to incorporate both the intended and applied 195 configurations. Support for "rollback on error" semantics 196 SHOULD be provided. 198 3. Separation of the applied configuration and derived state aspects 199 of operational state; ability to retrieve them independently and 200 together 202 A. Be able to retrieve only the applied configuration aspects of 203 operational state 205 B. Be able to retrieve only the derived state aspects of 206 operational state 208 C. Be able to retrieve both the applied configuration and 209 derived state aspects of operational state together 211 4. Ability to relate configuration with its corresponding 212 operational state 214 A. Ability to relate intended config nodes to corresponding 215 applied config nodes 217 B. Ability to relate intended config nodes to associated derived 218 state nodes 220 C. The relationships need to be programmatically consumable 222 5. Backwards compatibility 224 A. It MUST be possible to upgrade a server to one that supports 225 the solution without breaking existing/legacy clients. 227 B. It MUST be possible for a client that has been coded to 228 support the solution to interoperate appropriately with 229 existing/legacy servers. 231 4. Security Considerations 233 It is understood that the intended and applied configurations will 234 differ while synchronization is in progress. During the 235 synchronization process, the server will be in an inconsistent state 236 from the client's perspective. Implementations need to take care to 237 ensure that this process minimizes gaps in the application of 238 security policy (e.g., replacing a firewall policy in a single step). 239 Implementations additionally need to ensure that any gaps in security 240 policies are not dependent on external input that an attacker might 241 be able to control or prevent access to. 243 5. IANA Considerations 245 None 247 6. Acknowledgements 249 The authors would like to thank the following for contributing to 250 this document (in alphabetic order): Acee Lindem, Andy Bierman, Anees 251 Shaikh, Benoit Claise, Carl Moberg, Dan Romascanu, Dean Bogdanovic, 252 Gert Grammel, Jason Sterne, Jonathan Hansford, Juergen Schoenwaelder, 253 Lou Berger, Mahesh Jethanandani, Martin Bjorklund, Phil Shafer, Randy 254 Presuhn, Rob Shakir, Robert Wilton. 256 7. References 258 7.1. Normative References 260 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 261 Requirement Levels", BCP 14, RFC 2119, 262 DOI 10.17487/RFC2119, March 1997, 263 . 265 7.2. Informative References 267 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 268 and A. Bierman, Ed., "Network Configuration Protocol 269 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 270 . 272 [RFC6244] Shafer, P., "An Architecture for Network Management Using 273 NETCONF and YANG", RFC 6244, DOI 10.17487/RFC6244, June 274 2011, . 276 Authors' Addresses 278 Kent Watsen 279 Juniper Networks 281 EMail: kwatsen@juniper.net 283 Thomas Nadeau 284 Brocade Networks 286 EMail: tnadeau@lucidvision.com