idnits 2.17.1 draft-wu-netconf-nmda-compatibility-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 : ---------------------------------------------------------------------------- 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 (December 19, 2018) is 1926 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: 'RFC8174' is mentioned on line 123, but not defined == Missing Reference: 'RFC6243' is mentioned on line 222, but not defined == Unused Reference: 'RFC7950' is defined on line 396, but no explicit reference was found in the text Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NETCONF Working Group Q. Wu 3 Internet-Draft C. Feng 4 Intended status: Standards Track Huawei 5 Expires: June 22, 2019 December 19, 2018 7 NMDA Backwards-Compatibility with Legacy Devices 8 draft-wu-netconf-nmda-compatibility-00 10 Abstract 12 NMDA architectural framework eliminates the need to duplicate data 13 structures to provide separate configuration and operational state 14 sections and uses different datastores and new protocol operations to 15 distinct configuration from operation state. However when a server 16 needs to support both NMDA client and non-NMDA clients, it is not 17 clear whether a NMDA compliant server can use existing operation to 18 return the same results with as non-NMDA-aware server 19 does. 21 This document identifies some of the major challenges, and provides 22 solutions that are able to mitigate those challenges and smooth the 23 migration towards NMDA deployment. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at https://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on June 22, 2019. 42 Copyright Notice 44 Copyright (c) 2018 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (https://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 61 2. Problems . . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 2.1. NMDA Client vs Non-NMDA Client . . . . . . . . . . . . . 4 63 2.2. NETCONF Server Back-Compatibility . . . . . . . . . . . . 4 64 2.3. Feed System Configuration Back into Running Datastore . . 4 65 3. Solution . . . . . . . . . . . . . . . . . . . . . . . . . . 4 66 3.1. Client Support on NMDA . . . . . . . . . . . . . . . . . 4 67 3.2. Default handling Behaviour . . . . . . . . . . . . . . . 5 68 3.2.1. Default-Handling Basic Modes . . . . . . . . . . . . 5 69 3.2.2. get/get-config Operation . . . . . . . . . . . . . . 6 70 3.2.3. get-data Operation . . . . . . . . . . . . . . . . . 6 71 3.3. Protocol Operation Clarification . . . . . . . . . . . . 6 72 3.3.1. . . . . . . . . . . . . . . . . . . . . . . . . 6 73 3.3.2. . . . . . . . . . . . . . . . . . . . . 7 74 3.3.3. . . . . . . . . . . . . . . . . . . . . 7 75 3.3.4. . . . . . . . . . . . . . . . . . . . . . 8 76 3.3.5. . . . . . . . . . . . . . . . . . . . . . 8 77 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 78 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 79 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 80 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 81 7.1. Normative References . . . . . . . . . . . . . . . . . . 9 82 7.2. Informative References . . . . . . . . . . . . . . . . . 9 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 85 1. Introduction 87 NMDA architectural framework introduces additional datastores for 88 systems that support more advanced processing chains converting 89 configuration to operational state. It eliminates the need to 90 duplicate data structures to provide separate configuration and 91 operational state sections and uses different datastores and new 92 protocol operations (e.g.,, to distinct 93 configuration from operation state. 95 However when a server needs to support both NMDA client and non-NMDA 96 clients, it is not clear whether a NMDA compliant server can return 97 the same results with to non-NMDA clients as non-NMDA- 98 aware server does since the system configuration and default 99 configuration originally part of conventional configuration 100 datastores have been separated and moved to operational state 101 datastore. Also it is not clear whether the server should maintain 102 backwards-compatibility when the server is upgraded from non-NMDA- 103 aware server to NMDA compliant server. 105 NMDA Transition Guidelines in section 4.23.3 of [RFC8407] only 106 provides guidelines to transform non-NMDA compliant model into NMDA 107 compatible model, but doesn't provide guidelines on whether existing 108 NETCONF protocol operations such as get/get-config/edit-config 109 changes behaviour or semantics when they are exchanged between the 110 client and the server. 112 This document identifies some of the major challenges, and provides 113 solutions that are able to address those challenges which provide 114 smooth migration towards NMDA deployment. 116 1.1. Terminology 118 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 119 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 120 "OPTIONAL" in this document are to be interpreted as described in BCP 121 14 [RFC2119] [RFC8174] when, and only when, they appear in all 122 capitals, as shown here. 124 The following terms are defined in [RFC8342] and are not redefined 125 here: 127 o startup configuration datastore 129 o candiate configuration datastore 131 o running configuration datastore 133 o intended configuration datastore 135 o operational state datastore 137 The following terms are defined in this document: 139 Server Backwards-Compatibility: The client can use the same 140 protocol operation to get the same results from both NMDA 141 compliant server and Non NMDA server. 143 2. Problems 145 2.1. NMDA Client vs Non-NMDA Client 147 When a server is upgraded to NMDA compliant server and needs to 148 support both NMDA client and non-NMDA clients, there is no way for 149 the server to know whether the client supports NMDA. 151 2.2. NETCONF Server Back-Compatibility 153 When a server is upgraded to NMDA compliant server and needs to 154 support both NMDA client and non-NMDA clients, without NETCONF server 155 backwards-comability, a NMDA compliant server can return the results 156 with to non-NMDA clients different from non-NMDA-aware 157 server does. Since the system configuration and default 158 configuration originally part of conventional configuration 159 datastores have been separated and moved to operational state 160 datastore. For non-NMDA client, the configuration retrieved by on the running datastore will be reduced without including 162 system configuration and default configuration set by the server. 163 Non-NMDA client also has no way to retrieve system configuration 164 without new operations support on operational state datstore. 166 2.3. Feed System Configuration Back into Running Datastore 168 As we know, the system configuration and default configuration 169 originally part of conventional configuration datastores have been 170 separated and moved to operational state datastore. When further 171 configuration is needed within the system configuration,e.g., 172 configure IP address of the interface after such interface 173 configuration (i.e.,system configuration) is auto-created, such auto- 174 created interface configuration needs to set by the client. The 175 effect is the same as feeding auto-created interface configuration 176 into running datastore and make it become client set configuration. 177 After the interface configuration is applied, it will be merged with 178 the current system configuration in the operational state datastore. 180 3. Solution 182 3.1. Client Support on NMDA 184 When a sever needs to support both NMDA client and non-NMDA clients, 185 server support on NMDA can be advertised to the client via capability 186 identifier :yang-library:1.1 to the client. Client support on NMDA 187 can be indicated by protocol operations. If // operation is recieved from the client, the 189 server should assume the client is Non-NMDA client. If / operation is recieved from the client, the server 191 should assume the client is NMDA client. 193 Editor-Note: There are three ways to Indicate client support on NMDA: 195 1. Define capability identifier for client support on NMDA and 196 advertising this capability identifier to the server; 198 2. Use new or old protocol operation to indicate client support on 199 NMDA; 201 3. Use whether module type is NMDA compliant to indicate client 202 support on NMDA; 204 Either advertising capability identifier to the server or using 205 module type to indicate client support on NMDA adds server 206 implementation complexity. We argue to use protocol operation to 207 indicate whether the client support NMDA. 209 3.2. Default handling Behaviour 211 With-default capability defined in [RFC6243] is designed for 212 conventional configuration datatore. When NMDA is introduced, [I- 213 D.ietf-netconf-nmda-netconf] defines with-operational-defaults 214 capability and applies "with-defaults" parameter to 215 operations that target . However when default 216 configuration is separated from conventional configuration datastore, 217 the behaviour and semantics of "with-defaults" parameter also make a 218 few changes. 220 3.2.1. Default-Handling Basic Modes 222 A server still supports three basic modes defined in [RFC6243] for 223 handling default data. The' report-all' basic mode should be treated 224 in the same way as 'explicit' basic model since default configuration 225 has been moved to operational state datastore and therefore the 226 server should not consider the default configuration is part of 227 conventional configuration datastore unless it is explicitly set by 228 the client. 230 3.2.1.1. 'report-all' Basic Mode Retrieval 232 When data is retrieved from a server using the 'report-all' basic 233 mode, and the parameter is not present, data nodes 234 MUST be reported if explicitly set by the client, even if they 235 contain the schema default value. 237 3.2.1.2. 'report-all' and Behaviour 239 For backwards compatibility consideration, the server consider the 240 default data part of conventional configuration datastore. A valid 241 'create' operation attribute for a data node that has been set by a 242 server to its schema default value MUST fail with a 'data-exists' 243 error-tag. A valid 'delete' operation attribute for a data node that 244 has been set by a server to its schema default value MUST succeed. 246 3.2.1.3. 'report-all' Behaviour 248 If the "with-defaults" capability is supported by the server, the 249 "report-all" basic mode, defined in section 3.2.1.1, is supported for 250 operations that target conventional configuration 251 datastores. 253 A valid 'create' operation attribute for a data node that has been 254 set by a server to its schema default value MUST succeed. A valid 255 'delete' operation attribute for a data node that has been set by a 256 server to its schema default value MUST fail with a 'data-missing' 257 error-tag. 259 3.2.2. get/get-config Operation 261 For backwards compatibility consideration, when the basic mode is set 262 to 'report-all' or "with-defaults" parameter is set to report all, 263 the server should return all the data based on filtering selection 264 criteria including all the data from conventional configuration 265 datastore and default configuration from operational state datastore. 267 3.2.3. get-data Operation 269 When the basic mode is set to report-all or "with-defaults" parameter 270 is set to report all, the server should return all the data based on 271 filtering selection criteria including all the data from conventional 272 configuration datastore, but not include default configuration from 273 operational state datastore unless they are explicitly set by the 274 client. 276 3.3. Protocol Operation Clarification 278 3.3.1. 280 As described in [RFC6241], the NETCONF operation returns the 281 contents of together with the operational state. 283 If both the client and the server support NMDA and the client sends 284 request, the server should assume the client is non-NMDA client 285 and retrieve running configuration and device state from operational 286 state datastore and return it together with the system configuration 287 to the client in . 289 If the server supports NMDA and the client doesn't support NMDA, when 290 the client sends request, the server should retrieve running 291 configuration and device state from operational state datastore and 292 return the same results as it retrieves from non-NMDA aware server. 294 For default handling basic modes, please refer to Section 3.2.2. 296 3.3.2. 298 As described in [RFC6241], the NETCONF operation can be 299 used to retrieve all or part of a specified configuration datastore. 301 If both the client and the server support NMDA and the client sends 302 request, the server should assume the client is non-NMDA 303 client and retrieve specified configuration from together 304 with system configuration. 306 If the server supports NMDA and the client doesn't support NMDA, when 307 the client send request, the server should retrieve 308 specified configuration from together with system 309 configuration and return the same result as it retrieves from non- 310 NMDA aware server. 312 For default handling basic modes, please refer to Section 3.2.2. 314 3.3.3. 316 As described in [RFC6241], the NETCONF operation can be 317 used to load all or part of a specified configuration to the 318 specified target configuration datastore. 320 If the client wants to have further configuration based on system 321 configuration,(e.g.,configure IP address within auto-created physical 322 interface configuration),the server should create corresponding 323 physical interface with IP address configuration without error to be 324 returned to the client as long as IP address configuration is valid. 325 The effect is the same as the physical interface has already been 326 part of conventional configuration datastore. If the system 327 configuration is set by client sending operation 328 request, the error should be returned as if the system configuration 329 is part of conventional configuration datastore. 331 For default handling basic modes, please refer to Section 3.2.1.2. 333 3.3.4. 335 As described in [I-D.ietf-netconf-nmda-netconf], the 336 operation retrieves data from a specific NMDA datastore,similar to 337 NETCONF's operation defined in [RFC6241]. 339 If the client sends request with specified target 340 configuration datastore set to running datastore, the server should 341 assume the client is NMDA client and retrieve specified configuration 342 from without system configuration set by the server since 343 system configuration is separated from conventional configuration 344 datastore. 346 For default handling basic modes, please refer to Section 3.2.3. 348 3.3.5. 350 As described in [I-D.ietf-netconf-nmda-netconf], the NETCONF operation can be used to load all or part of a specified 352 configuration to the specified target configuration datastore. 354 For NMDA client sending operation request with specified 355 target configuration datastore set to configuration datastore such as 356 running datastore, since system configuration is separated from 357 conventional configuration datastore, if the client wants to use 358 system configuration or configure other parameter(e.g., IP address) 359 within system configuration(e.g., auto-created interface 360 configuration), Explicitly creating system configuration by the 361 client MUST be allowed without error being returned. For default 362 configuration, since it doesn't exist in the conventional 363 configuration datastore, the default configuration MUST be created 364 without error being returned, irrespectively "with-defaults" 365 parameter being set to basic-mode, trim or report-all. 367 4. IANA Considerations 369 There is no IANA action in this document. 371 5. Security Considerations 373 This document does not introduce any security vulnerability besides 374 one defined in [RFC6241] [I-D.ietf-netconf-nmda-netconf]. 376 6. Acknowledgements 378 Thanks Robert Wilton,Guangying Zheng,Shouchuan Yang,Dan Qu, Ye Niu to 379 discuss NMDA comability issues on existing protocol operation and 380 provide important input to this document. 382 7. References 384 7.1. Normative References 386 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 387 Requirement Levels", BCP 14, RFC 2119, 388 DOI 10.17487/RFC2119, March 1997, 389 . 391 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 392 and A. Bierman, Ed., "Network Configuration Protocol 393 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 394 . 396 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 397 RFC 7950, DOI 10.17487/RFC7950, August 2016, 398 . 400 [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., 401 and R. Wilton, "Network Management Datastore Architecture 402 (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018, 403 . 405 [RFC8407] Bierman, A., "Guidelines for Authors and Reviewers of 406 Documents Containing YANG Data Models", BCP 216, RFC 8407, 407 DOI 10.17487/RFC8407, October 2018, 408 . 410 7.2. Informative References 412 [I-D.ietf-netconf-nmda-netconf] 413 Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., 414 and R. Wilton, "NETCONF Extensions to Support the Network 415 Management Datastore Architecture", draft-ietf-netconf- 416 nmda-netconf-08 (work in progress), October 2018. 418 Authors' Addresses 420 Qin Wu 421 Huawei 422 101 Software Avenue, Yuhua District 423 Nanjing, Jiangsu 210012 424 China 426 Email: bill.wu@huawei.com 427 Chong Feng 428 Huawei 429 101 Software Avenue, Yuhua District 430 Nanjing, Jiangsu 210012 431 China 433 Email: frank.fengchong@huawei.com