idnits 2.17.00 (12 Aug 2021) /tmp/idnits1119/draft-wu-netconf-nmda-compatibility-01.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 (March 9, 2019) is 1162 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 131, but not defined == Missing Reference: 'RFC6243' is mentioned on line 234, but not defined == Unused Reference: 'RFC7950' is defined on line 422, but no explicit reference was found in the text == Outdated reference: draft-ietf-netconf-nmda-netconf has been published as RFC 8526 Summary: 0 errors (**), 0 flaws (~~), 5 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: September 10, 2019 March 9, 2019 7 NMDA protocol operation Backwards-Compatibility with Legacy Devices 8 draft-wu-netconf-nmda-compatibility-01 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 non-NMDA 16 clients communicate with NMDA aware server, it is not clear whether 17 the NMDA aware server can use existing operation to return the same 18 results with as non-NMDA-aware server does. 20 This document identifies some of the major challenges, and provides 21 solutions that are able to mitigate those challenges and smooth the 22 migration towards NMDA deployment. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at https://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on September 10, 2019. 41 Copyright Notice 43 Copyright (c) 2019 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (https://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Problems . . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 2.1. NMDA Client vs Non-NMDA Client . . . . . . . . . . . . . 4 62 2.2. NETCONF Server Back-Compatibility . . . . . . . . . . . . 4 63 2.3. Feed System Configuration Back into Running Datastore . . 4 64 3. Solution . . . . . . . . . . . . . . . . . . . . . . . . . . 5 65 3.1. Client NMDA Support . . . . . . . . . . . . . . . . . . . 5 66 3.2. Default handling Behaviour . . . . . . . . . . . . . . . 5 67 3.2.1. Default-Handling Basic Modes . . . . . . . . . . . . 5 68 3.2.2. get/get-config Operation . . . . . . . . . . . . . . 6 69 3.2.3. get-data Operation . . . . . . . . . . . . . . . . . 7 70 3.3. Protocol Operation Clarification . . . . . . . . . . . . 7 71 3.3.1. . . . . . . . . . . . . . . . . . . . . . . . . 7 72 3.3.2. . . . . . . . . . . . . . . . . . . . . 7 73 3.3.3. . . . . . . . . . . . . . . . . . . . . 8 74 3.3.4. . . . . . . . . . . . . . . . . . . . . . 8 75 3.3.5. . . . . . . . . . . . . . . . . . . . . . 8 76 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 77 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 78 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 79 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 9 80 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 81 8.1. Normative References . . . . . . . . . . . . . . . . . . 9 82 8.2. Informative References . . . . . . . . . . . . . . . . . 10 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 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 NMDA client communicates with NMDA aware server, it is 96 not clear whether the NMDA aware server can return the same results 97 with to non-NMDA clients as non-NMDA-aware server does 98 since the system configuration and default configuration originally 99 part of conventional configuration datastores have been explicitly 100 separated and moved to operational state datastore under NMDA 101 architecture. Also it is not clear whether the server should 102 maintain protocol operation backwards-compatibility when the NMDA 103 aware server is upgraded from non-NMDA-aware server to NMDA aware 104 server. 106 NMDA Transition Guidelines in section 4.23.3 of [RFC8407] only 107 provides guidelines to transform non-NMDA compliant model into NMDA 108 compatible model, but doesn't provide guidelines on whether existing 109 NETCONF protocol operations such as get/get-config/edit-config change 110 semantics when they are exchanged between the non NMDA client and the 111 NMDA arware server. 113 This document identifies some of the major challenges, and provides 114 solutions that are able to address those challenges which provide 115 smooth migration towards NMDA deployment. 117 o Use protocol operation to indicate whether the client NMDA 118 support. 120 o An extension to Default handling Behaviour. 122 o Protocol Operation Clarification. 124 1.1. Terminology 126 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 127 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 128 "OPTIONAL" in this document are to be interpreted as described in BCP 129 14 [RFC2119] [RFC8174] when, and only when, they appear in all 130 capitals, as shown here. 132 The following terms are defined in [RFC8342] and are not redefined 133 here: 135 o startup configuration datastore 137 o candiate configuration datastore 139 o running configuration datastore 141 o intended configuration datastore 143 o operational state datastore 144 The following terms are defined in this document: 146 Server Protocol Operation Backwards-Compatibility: The client can 147 use the same protocol operation to get the same results from both 148 NMDA compliant server and Non NMDA server. 150 2. Problems 152 2.1. NMDA Client vs Non-NMDA Client 154 When a server is upgraded to NMDA aware server and needs to support 155 both NMDA client and non-NMDA clients, there is no standards-based 156 way for the server to know whether the client supports NMDA. 158 2.2. NETCONF Server Back-Compatibility 160 When a server is upgraded to NMDA server and needs to support both 161 NMDA client and non-NMDA clients, without NETCONF server protocol 162 operation backwards-comability, a NMDA server can return the results 163 with to non-NMDA clients different from non-NMDA-aware 164 server does. Since in some cases ('report-all' Retrieval Mode or 165 client set Explicit Mode) default configuration originally part of 166 conventional configuration datastores have been explicitly separated 167 and moved to operational state datastore, so does the system 168 configuration. For non-NMDA client, the configuration retrieved by 169 on the running datastore will be reduced without 170 including system configuration and default configuration set by the 171 server. Non-NMDA client also has no way to retrieve system 172 configuration without new operations support on operational state 173 datstore. 175 2.3. Feed System Configuration Back into Running Datastore 177 As we know, the system configuration and default configuration 178 originally part of conventional configuration datastores before NMDA 179 is introduced have been separated and moved to operational state 180 datastore. When further configuration is needed within the system 181 configuration, e.g., configure IP address of the interface after such 182 interface configuration (i.e.,system configuration) is auto-created, 183 such auto-created interface configuration needs to set by the client 184 since it doesn't exist in the conventional configuration datastore. 185 The effect is the same as feed auto-created interface configuration 186 into running datastore and make it become client set configuration. 187 After the interface configuration is applied, it will be merged with 188 the other existing system configuration in the operational state 189 datastore. 191 3. Solution 193 3.1. Client NMDA Support 195 When a NMDA aware sever needs to support both NMDA client and non- 196 NMDA clients, server NMDA support can be advertised to the client via 197 capability identifier :yang-library:1.1 to the client. Client NMDA 198 support should be indicated by protocol operations. If // operation is recieved from the client, the 200 server should assume the client is Non-NMDA client. If / operation is recieved from the client, the server 202 should assume the client is NMDA client. 204 Editor-Note: There are three ways to Indicate client support on NMDA: 206 1. Define capability identifier for client NMDA support and 207 advertising this capability identifier to the server; 209 2. Use new or old protocol operation to indicate client NMDA 210 support; 212 3. Use whether module type is NMDA aware to indicate client NMDA 213 support ; 215 Either advertising capability identifier to the server or using 216 module type to indicate client NMDA support adds server 217 implementation complexity. We argue to use protocol operation to 218 indicate whether the client support NMDA. 220 3.2. Default handling Behaviour 222 With-default capability defined in [RFC6243] is designed for 223 conventional configuration datatore. As described in [I-D.ietf- 224 netconf-nmda-netconf], semantics for "with-defaults" in 225 operations is the same as for , as described in section 226 4.5.2 of [RFC6243]. However when the NMDA is introduced, the default 227 configuration is clearly separated from conventional configuration 228 datastore, the semantics of "with-defaults" parameter have made a few 229 changes. 231 3.2.1. Default-Handling Basic Modes 233 A NMDA aware server still supports three basic modes defined in 234 [RFC6243] for handling default data. In addition to 'report-all' 235 Retrieval Mode, the 'report-all' basic mode should be also treated in 236 the same way as 'explicit' basic model in case of NMDA since the 237 default configuration has been moved to operational state datastore 238 and therefore the NMDA aware server should not consider the default 239 configuration is part of conventional configuration datastore unless 240 it is explicitly set by the client. 242 3.2.1.1. 'report-all' Basic Mode Retrieval 244 When the data is retrieved from a server using the 'report-all' basic 245 mode, and the parameter is not present, data nodes 246 MUST be reported if explicitly set by the client, even if they 247 contain the schema default value. 249 3.2.1.2. 'report-all' and Behaviour 251 For backwards compatibility consideration, the server consider the 252 default data part of conventional configuration datastore. A valid 253 'create' operation attribute for a data node that has been set by a 254 client to its schema default value MUST fail with a 'data-exists' 255 error-tag. A valid 'delete' operation attribute for a data node that 256 has been set by a client to its schema default value MUST succeed. 258 3.2.1.3. 'report-all' Behaviour 260 If the 'with-defaults' capability is supported by the server, the 261 'report-all' basic mode, defined in section 3.2.1.1, is supported for 262 operations that target conventional configuration 263 datastores. 265 A valid 'create' operation attribute for a data node that has been 266 set by a client to its schema default value MUST succeed. A valid 267 'delete' operation attribute for a data node that has been set by a 268 client to its schema default value MUST fail with a 'data-missing' 269 error-tag. 271 Since the default configuration doesn't exist in the conventional 272 configuration datastore, the default configuration MUST be created 273 without error being returned, irrespectively "with-defaults" 274 parameter being set to basic-mode, trim or report-all. 276 3.2.2. get/get-config Operation 278 For backwards compatibility consideration, when the basic mode is set 279 to 'report-all' or 'with-defaults' capability parameter is set to 280 report all, the NMDA aware server should return all the data based on 281 filtering selection criteria including all the data from conventional 282 configuration datastore and default configuration from operational 283 state datastore. 285 3.2.3. get-data Operation 287 When the basic mode is set to report-all or 'with-defaults' 288 capability parameter is set to report all, the NMDA aware server 289 should return all the data based on filtering selection criteria 290 including all the data from conventional configuration datastore, but 291 not include default configuration from operational state datastore 292 unless they are explicitly set by the client. 294 3.3. Protocol Operation Clarification 296 3.3.1. 298 As described in [RFC6241], the NETCONF operation returns the 299 contents of together with the operational state. 301 If the client supports NMDA and sends request to the NMDA aware 302 server, the server should assume the client is non-NMDA client and 303 retrieve specified configuration from running configuration and 304 system configuration from operational state datastore and return it 305 together with the system configuration to the client in . 307 If the client doesn't support NMDA and sends request to the 308 NMDA aware server, the server should retrieve running configuration 309 and system configuration from operational state datastore and return 310 the same results as it retrieves from non-NMDA aware server. 312 For default handling basic modes, please refer to Section 3.2.2. 314 3.3.2. 316 As described in [RFC6241], the NETCONF operation can be 317 used to retrieve all or part of a specified configuration datastore. 319 If the client supports NMDA and sends request to the 320 NMDA aware Server, the server should assume the client is non-NMDA 321 client and retrieve specified configuration from together 322 with the system configuration. 324 If the client doesn't support NMDA and send request to 325 the NMDA aware server, the server should retrieve 326 configuration together with the system configuration and return the 327 same result as it retrieves from non-NMDA aware server. 329 For default handling basic modes, please refer to Section 3.2.2. 331 3.3.3. 333 As described in [RFC6241], the NETCONF operation can be 334 used to load all or part of a specified configuration to the 335 specified target configuration datastore. 337 If the client sends request to the NMDA aware server 338 and wants to have further configuration based on the system 339 configuration,(e.g.,configure IP address within auto-created physical 340 interface configuration), the server should create IP address 341 configuration corresponding to specific physical interface without 342 error to be returned to the client as long as IP address 343 configuration is validated. The effect is the same as the physical 344 interface has already been part of conventional configuration 345 datastore. If the system configuration is set by the client sending 346 operation request, the error should be returned as if 347 the system configuration has already been part of conventional 348 configuration datastore. 350 For default handling basic modes, please refer to Section 3.2.1.2. 352 3.3.4. 354 As described in [I-D.ietf-netconf-nmda-netconf], the 355 operation retrieves data from a specific NMDA datastore,similar to 356 NETCONF's operation defined in [RFC6241]. 358 If the client sends request with specified target 359 configuration datastore set to the running datastore, the server 360 should assume the client is NMDA client and retrieve specified 361 configuration from without system configuration set by the 362 server since the system configuration is separated from conventional 363 configuration datastore. 365 For default handling basic modes, please refer to Section 3.2.3. 367 3.3.5. 369 As described in [I-D.ietf-netconf-nmda-netconf], the NETCONF operation can be used to load all or part of a specified 371 configuration to the specified target configuration datastore. 373 For the NMDA client sending operation request with 374 specified target configuration datastore set to the configuration 375 datastore such as running datastore, since the system configuration 376 is separated from conventional configuration datastore, if the NMDA 377 client wants to use system configuration or configure other parameter 378 (e.g., IP address) within system configuration(e.g., auto-created 379 interface configuration), Explicitly creating the system 380 configuration by the client MUST be allowed without error being 381 returned. 383 4. IANA Considerations 385 There is no IANA action in this document. 387 5. Security Considerations 389 This document does not introduce any security vulnerability besides 390 one defined in [RFC6241] [I-D.ietf-netconf-nmda-netconf]. 392 6. Acknowledgements 394 Thanks Robert Wilton,Guangying Zheng,Shouchuan Yang,Dan Qu, Ye Niu to 395 discuss NMDA comability issues on existing protocol operation and 396 provide important input to this document. 398 7. Contributors 400 Michael Wang 401 Huawei Technologies, Co., Ltd 402 101 Software Avenue, Yuhua District 403 Nanjing 210012 404 China 406 Email: wangzitao@huawei.com 408 8. References 410 8.1. Normative References 412 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 413 Requirement Levels", BCP 14, RFC 2119, 414 DOI 10.17487/RFC2119, March 1997, 415 . 417 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 418 and A. Bierman, Ed., "Network Configuration Protocol 419 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 420 . 422 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 423 RFC 7950, DOI 10.17487/RFC7950, August 2016, 424 . 426 [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., 427 and R. Wilton, "Network Management Datastore Architecture 428 (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018, 429 . 431 [RFC8407] Bierman, A., "Guidelines for Authors and Reviewers of 432 Documents Containing YANG Data Models", BCP 216, RFC 8407, 433 DOI 10.17487/RFC8407, October 2018, 434 . 436 8.2. Informative References 438 [I-D.ietf-netconf-nmda-netconf] 439 Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., 440 and R. Wilton, "NETCONF Extensions to Support the Network 441 Management Datastore Architecture", draft-ietf-netconf- 442 nmda-netconf-08 (work in progress), October 2018. 444 Authors' Addresses 446 Qin Wu 447 Huawei 448 101 Software Avenue, Yuhua District 449 Nanjing, Jiangsu 210012 450 China 452 Email: bill.wu@huawei.com 454 Chong Feng 455 Huawei 456 101 Software Avenue, Yuhua District 457 Nanjing, Jiangsu 210012 458 China 460 Email: frank.fengchong@huawei.com