idnits 2.17.1 draft-schoenw-netconf-light-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 (January 18, 2012) is 4482 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) -- Obsolete informational reference (is this intentional?): RFC 4347 (Obsoleted by RFC 6347) -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group V. Perelman 3 Internet-Draft J. Schoenwaelder 4 Intended status: Standards Track Jacobs University 5 Expires: July 21, 2012 M. Ersue 6 Nokia Siemens Networks 7 K. Watsen 8 Juniper Networks 9 January 18, 2012 11 Network Configuration Protocol Light (NETCONF Light) 12 draft-schoenw-netconf-light-01.txt 14 Abstract 16 This document describes a profile of the NETCONF protocol called 17 NETCONF Light. This profile modularizes the NETCONF protocol and 18 allows devices to announce that they only support a subset of the 19 NETCONF protocol operations. This is useful in situations where 20 devices are either too resource constrained to support all NETCONF 21 operations or where devices are gradually updated from proprietary 22 configuration interfaces to support NETCONF. 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 http://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 July 21, 2012. 41 Copyright Notice 43 Copyright (c) 2012 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 (http://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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 2.1. NETCONF on Constrained Devices . . . . . . . . . . . . . . 4 61 2.2. Gradually Adding NETCONF Support . . . . . . . . . . . . . 4 62 3. NETCONF Light Overview . . . . . . . . . . . . . . . . . . . . 6 63 3.1. Reduced Protocol Operations . . . . . . . . . . . . . . . 6 64 3.1.1. . . . . . . . . . . . . . . . . . . . . . 6 65 3.1.2. . . . . . . . . . . . . . . . . . . . . 7 66 3.1.3. . . . . . . . . . . . . . . . . . . . . 7 67 3.1.4. . . . . . . . . . . . . . . . . . . . 7 68 3.1.5. and . . . . . . . . . . . . . . . . . 7 69 3.1.6. . . . . . . . . . . . . . . . . . . . . . . . . 8 70 3.1.7. . . . . . . . . . . . . . . . . . . . 8 71 3.1.8. . . . . . . . . . . . . . . . . . . . . 8 72 3.2. Capability Negotiation . . . . . . . . . . . . . . . . . . 8 73 4. NETCONF Light YANG Module . . . . . . . . . . . . . . . . . . 10 74 5. IANA Consideration . . . . . . . . . . . . . . . . . . . . . . 14 75 6. Security Considerations . . . . . . . . . . . . . . . . . . . 15 76 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 77 7.1. Normative References . . . . . . . . . . . . . . . . . . . 16 78 7.2. Informative References . . . . . . . . . . . . . . . . . . 16 79 Appendix A. NETCONF Light on AVR Raven / Contiki . . . . . . . . 17 80 Appendix B. Experience at Juniper Networks . . . . . . . . . . . 18 82 1. Introduction 84 The Network Configuration Protocol (NETCONF) [RFC6241] provides 85 mechanisms to install, manipulate, and delete the configuration of 86 network devices. This document modularizes the NETCONF protocol and 87 allows devices to announce that they only support a subset of the 88 NETCONF protocol operations. This is useful in situations where 89 devices are either too resource constrained to support all NETCONF 90 operations or where devices are gradually updated from proprietary 91 configuration interfaces to support NETCONF. 93 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 94 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 95 document are to be interpreted as described in RFC 2119 [RFC2119]. 97 2. Motivation 99 This section explains the motiviation for NETCONF Light. 101 2.1. NETCONF on Constrained Devices 103 The original target of NETCONF were network devices such as routers 104 or switches that usually have plenty of resources for running a 105 NETCONF server. However, there are a number of embedded systems 106 where resources (most notably memory) are tight and hence such 107 devices can only afford a subset of the NETCONF protocol operations. 108 This document allows constrained devices to implement a subset of 109 NETCONF and to communicate that subset to NETCONF management 110 applications in an interoperable way. 112 The usage of NETCONF Light on resource constrained devices is 113 attractive in environments where management applications have to deal 114 with a wide range of different devices, for example ranging from very 115 small embedded networked sensors over more powerful data aggregation 116 servers up to highly complex control networks. Typical examples are 117 Smart Grids or more general industrial control networks. 119 Constrained devices can be classified according to the memory they 120 have. A recently proposed classification is the following: 122 o Class 0: too small to securely run on the Internet (too 123 constrained). 125 o Class 1: about 10 KiB of data and 100 KiB of code (quite 126 constrained, 10/100) 128 o Class 2: about 50 KiB of data and 250 KiB of code (not so 129 constrained, 50/250) 131 According to these classes, NETCONF Light should be running fine in 132 "not so constrained" Class 2 devices and it may be running in "quite 133 constrained" Class 1 devices, with very little resources left for 134 other application code. 136 2.2. Gradually Adding NETCONF Support 138 While the NETCONF protocol defines a number of capabilities that may 139 be optionally implemented, the base protocol remains a significant 140 effort to add for existing devices. For these devices, adding 141 support for NETCONF is primarily driven by a specific integration 142 target, thus the intrinsic goal is to have an initial release that 143 satisfies the integration target and a subsequent release that 144 implements the remainder of the NETCONF protocol. 146 Some scenarios where phasing in the imeplmentation would be helpful 147 include: 149 o The device's primary goal is to implement a vendor-specific 150 capability. In this case, the device is only using NETCONF for 151 its "Messages" layer (i.e. RPC, RPC-reply, and Notification). 153 o The device's primary goal is to just support read-only access to 154 its configuration. In this case, it only needs to implement initially, leaving the remaining operations for a future 156 release. 158 o The device's primary goal is to enable full configuration, but it 159 doesn't have the time to implement all the 160 operations. In this case, the device could implement just . 163 o The device's primary goal is to enable full configuration, but it 164 is unable to implement or due to its platform not 165 having a locking mechanism yet. 167 Each of these cases is satisfied by NETCONF Light, as the device can 168 adverise the specific subset of NETCONF operations it supports. The 169 ability for development teams to incrementally implement NETCONF 170 makes it a more appealing target for their short-term efforts. 172 3. NETCONF Light Overview 174 NETCONF Light uses the NETCONF message framing as defined in 175 [RFC6241]. In particular, it uses the same XML encoding and XML 176 namespace. 178 The NETCONF specification [RFC6241] defines a set of base operations 179 and a number of optional capabilities. A NETCONF Light 180 implementation may choose to not support all NETCONF base operations. 181 The set of operations supported by a NETCONF Light server is 182 announced to a NETCONF client as features, see the definition of the 183 ietf-netconf-light YANG [RFC6020] module in Section 4. 185 A NETCONF Light implementation, like any NETCONF implementation, does 186 not have to support any of the optional NETCONF capabilities. The 187 normal NETCONF rules apply for the capability exchange with 188 messages. 190 A NETCONF Light implementation may support only a limited number of 191 concurrent sessions. On some devices, the number of concurrent 192 sessions might be as low as one. A NETCONF Light implementation 193 supporting only a limited number of sessions should reject the 194 establishment of a new transport, i.e., it should not even start the 195 NETCONF exchange. 197 3.1. Reduced Protocol Operations 199 The following sections describe the changes to the NETCONF base 200 protocol operations. 202 3.1.1. 204 A NETCONF Light implementation MAY choose to not support the operation as defined in Section 7.1 of [RFC6241]. 206 Furthermore, a NETCONF Light implementation MAY choose to support 207 without filtering. An implementation not supporting the 208 operation MUST return an element with an 209 value of "operation-not-supported" when an 210 operation is invoked. If a operation is invoked with a 211 element and filtering is not supported, an 212 element MUST be returned with an value of "unknown- 213 element". 215 Note that [RFC6241] only requires to support the datastore 216 as source parameter. 218 3.1.2. 220 A NETCONF Light implementation supporting only a small data model MAY 221 choose to not support the operation defined in Section 222 7.2 of [RFC6241]. An implementation not supporting the 223 operation MUST return an element with an 224 value of "operation-not-supported" when an operation is 225 invoked. 227 3.1.3. 229 A NETCONF Light implementation MAY choose to not support the as defined in Section 7.3 of [RFC6241]. An implementation 231 not supporting the operation MUST return an 232 element with an value of "operation-not-supported" when a 233 operation is invoked. 235 Note that [RFC6241] only requires to support the datastore 236 as source parameter. If no other capabilities are announced, the 237 source parameter of the operation will carry the 238 element containing the complete configuration to copy. 240 3.1.4. 242 A NETCONF Light implementation MAY choose to not support the operation as defined in Section 7.4 of [RFC6241]. An 244 implementation not supporting the operation MUST 245 return an element with an value of 246 "operation-not-supported" when a operation is 247 invoked. 249 Note that NETCONF implementations only supporting the 250 datastore can trivially implement by always returning 251 a suitable since the datastore cannot be 252 deleted. 254 3.1.5. and 256 A NETCONF Light implementation MAY choose to not support the 257 and operations as defined in Sections 7.5 and 7.6 of 258 [RFC6241]. An implementation not supporting the operation or 259 the operation MUST return an element with an 260 value of "operation-not-supported" when a 261 operation is invoked. 263 3.1.6. 265 A NETCONF Light implementations MAY choose to not support the 266 operation as defined in Section 7.7 of [RFC6241]. An implementation 267 not supporting the operation MUST return an element 268 with an value of "operation-not-supported" when a 269 operation is invoked. 271 Some implementations MAY choose to support the operation with 272 the following restriction: A NETCONF Light implementation MAY choose 273 to not support filtering. If a operation is invoked with a 274 element and filtering is not supported, an 275 element MUST be returned with an value of "unknown- 276 element". 278 3.1.7. 280 A NETCONF Light implementation MAY choose to not support the operation as defined in Section 7.8 of [RFC6241]. An 282 implementation not supporting the operation MUST 283 return an element with an value of 284 "operation-not-supported" when a operation is 285 invoked. 287 3.1.8. 289 A NETCONF Light implementation MAY choose to not support the operation as defined in Section 7.9 of [RFC6241]. An 291 implementation not supporting the operation MUST 292 return an element with an value of 293 "operation-not-supported" when a operation is invoked. 295 3.2. Capability Negotiation 297 NETCONF advertises the capabilities during the exchange (see 298 Section 8.1 of [RFC6241]). The NETCONF base capability, 299 "urn:ietf:params:netconf:base:1.1", indicates that the NETCONF peer 300 supports all the base protocol operations. Since this is not the 301 case for NETCONF Light implementations, a NETCONF Light peer MUST NOT 302 announce the NETCONF base capability and instead announce the NETCONF 303 light capability. 305 In the following example, a NETCONF Light server advertises the 306 NETCONF Light capability and support for the and operation (whitespace has been added for readability). 309 310 311 312 urn:ietf:params:xml:ns:yang:ietf-netconf-light? 313 module=ietf-netconf-light& 314 revision=2012-01-12& 315 features=get-config,copy-config 316 317 318 4 319 321 4. NETCONF Light YANG Module 323 This section defines the ietf-netconf-light YANG [RFC6020] module. 325 file "ietf-netconf-light@2012-01-12.yang" 327 module ietf-netconf-light { 329 namespace "urn:ietf:params:xml:ns:yang:ietf-netconf-light"; 330 prefix "ncl"; 332 organization 333 "IETF NETCONF (Network Configuration Protocol) Working Group"; 335 contact 336 "WG Web: 337 WG List: 339 WG Chair: Bert Wijnen 340 342 WG Chair: Mehmet Ersue 343 345 Editor: Vladislav Perelman 346 348 Editor: Juergen Schoenwaelder 349 351 Editor: Mehmet Ersue 352 354 Editor: Kent Watsen 355 "; 357 description 359 "This module defines the base NETCONF protocol defined in RFC 6241 360 as a suite of optionally implemented features. The NETCONF Light 361 capability is expected to be advertized in the server's 362 message in lieu of the traditional base NETCONF capability. By 363 advertizing this capability, servers can indentify which parts of 364 the NETCONF protocol are supported. For the most part, NETCONF 365 Light defines a one-to-one mapping between base protocol 366 operations and features enabling them; exceptions include 367 , which has one feature to enable the RPC and another 368 to enable subtree-filtering, and /, which share a 369 feature called \"locking\". Advertizing all NETCONF Light 370 features is equivalent to advertizing the NETCONF base capability 371 itself. 373 Copyright (c) 2012 IETF Trust and the persons identified as 374 authors of the code. All rights reserved. 376 Redistribution and use in source and binary forms, with or 377 without modification, is permitted pursuant to, and subject 378 to the license terms contained in, the Simplified BSD 379 License set forth in Section 4.c of the IETF Trust's 380 Legal Provisions Relating to IETF Documents 381 (http://trustee.ietf.org/license-info). 383 This version of this YANG module is part of RFC XXXX; see 384 the RFC itself for full legal notices."; 385 // RFC Ed.: replace XXXX with actual RFC number and 386 // remove this note 388 // RFC Ed.: remove this note 389 // Note: extracted from draft-schoenw-netconf-light-01.txt 391 // RFC Ed.: please update the date to the date of publication 393 revision 2012-01-12 { 394 description "Initial version."; 395 reference "RFC XXXX: Network Configuration Protocol for 396 Constrained Devices (NETCONF Light)"; 397 } 398 // RFC Ed.: replace XXXX with actual 399 // RFC number and remove this note 401 feature get-config { 402 description 403 "This feature indicates that the server supports the 404 protocol operation, albeit without subtree 405 filtering. The server must additionally advertize 406 the \"subtree-filtering\" feature to enable subtree 407 filtering. Alternatively, if the server only wants 408 to support XPath filtering, it may just advertize 409 the :xpath capability."; 410 } 412 feature subtree-filtering { 413 description 414 "This feature indicates that the server supports subtree 415 filtering for the operation. This 416 feature is only meaningful if the "get-config" feature 417 is advertized; if "get-config" is not also advertized, 418 this feature MUST be ignored."; 419 } 421 feature edit-config { 422 description 423 "This feature indicates that the server supports the 424 protocol operation. If the server is 425 unable to support all the attributes 426 (merge, replace, create, delete, remove), then it 427 should advertize the \"copy-config\" feature instead."; 428 } 430 feature copy-config { 431 description 432 "This feature indicates that the server supports the 433 protocol operation."; 434 } 436 feature delete-config { 437 description 438 "This feature indicates that the server supports the 439 protocol operation."; 440 } 442 feature locking { 443 description 444 "This feature indicates that the server supports the 445 and protocol operations."; 446 } 448 feature get { 449 description 450 "This feature indicates that the server supports the 451 protocol operation."; 452 } 454 feature close-session { 455 description 456 "This feature indicates that the server supports the 457 protocol operation. When this feature 458 is not advertized, clients are expected to close the 459 underlying transport directly."; 460 } 462 feature kill-session { 463 description 464 "This feature indicates that the server supports the 465 protocol operation."; 466 } 467 } 469 471 5. IANA Consideration 473 This document registers a URI in the IETF XML registry [RFC3688]. 474 Following the format in RFC 3688, the following registration is 475 requested. 477 URI: urn:ietf:params:xml:ns:yang:ietf-netconf-light 479 Registrant Contact: The NETCONF WG of the IETF. 481 XML: N/A, the requested URI is an XML namespace. 483 This document registers a YANG module in the YANG Module Names 484 registry [RFC6020]. 486 name: ietf-netconf-light 487 namespace: urn:ietf:params:xml:ns:yang:ietf-netconf-light 488 prefix: ncl 489 reference: RFC XXXX 491 6. Security Considerations 493 NETCONF requires every implementation to support the SSH transport 494 (Section 2.3 of [RFC6241]). On resource constrained devices, it is 495 crucial that a single security protocol can be shared between 496 different application protocols. While SSH tends to be popular for 497 remote login services, it seems that TLS [RFC5246] and its datagram 498 cousin DTLS [RFC4347] are enjoying much greater support on small 499 embedded devices. Hence it might be necessary to choose a different 500 mandatory to implement secure transport protocol for NETCONF Light. 502 7. References 504 7.1. Normative References 506 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 507 Requirement Levels", BCP 14, RFC 2119, March 1997. 509 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 510 January 2004. 512 [RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the 513 Network Configuration Protocol (NETCONF)", RFC 6020, 514 October 2010. 516 [RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A. 517 Bierman, "Network Configuration Protocol (NETCONF)", 518 RFC 6241, June 2011. 520 7.2. Informative References 522 [RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 523 Security", RFC 4347, April 2006. 525 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 526 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 528 Appendix A. NETCONF Light on AVR Raven / Contiki 530 An implementation of NETCONF Light on Contiki operating system has 531 been created. It is running on AVR Raven motes, which are Class 1 532 devices. The implementation is compliant with this Internet-Draft. 533 It does not support filtering, or any other optional 534 NETCONF capabilities. NETCONF messages are currently transported 535 over plain TCP connections. 537 Together with the Contiki operating system (which weighs about 10 KiB 538 RAM) and the System Manager application (0.4 KiB RAM), which is used 539 for retrieval of the operational state of the device, NETCONF Light 540 takes 13 KiB RAM out of 16 KiB RAM available. The operating system 541 together with the NETCONF Light implementation uses 78 KiB out of 128 542 KiB flash memory. This means that the current implementation of the 543 protocol itself takes 2.6 KiB RAM - a value, that can be lowered by 544 further code optimizations. 12 KiB out of the used 78 KiB of flash 545 memory are reserved for the four files in the Coffee File System. 546 These files are used for input / output manipulations in order to 547 avoid using more RAM than needed. The size of the files can be 548 changed if needed, however, it is not advisable to make the files 549 larger since this will constrain usage of the flash memory by other 550 applications. After installing NETCONF Light the device has 3.5 KiB 551 of RAM free, which can be used by other applications. 553 Appendix B. Experience at Juniper Networks 555 Following are three case studies where NETCONF Light would have 556 helped. 558 As a disclaimer, please note that in accordance with the RFC, Juniper 559 does not claim its devices implement NETCONF or let them listen on 560 port 830 until the entire NETCONF protocol has been implemented. 562 o Juniper Networks' device management strategy depends on NETCONF 563 or, more precisely, on NETCONF plus capabilities we've defined to 564 support various aspects of the device (system, hardware, software, 565 licenses, etc.). In order to integrate with Juniper's NMS system, 566 a device must support a number of these capabilities before the 567 NMS will even attempt to configure the device. Thus it is common 568 that devices new to Juniper, either OEM'ed from a partner or 569 obtained through acquisistion, to initially support just the RPCs 570 needed for the most basic support by Juniper's NMS and then 571 implement the rest of the NETCONF protocol in a subsequent 572 release. 574 o As an extension to the previous example, it's not uncommon for a 575 device to intially support configuration using its native 576 configuration format, which is typically not XML. However, since 577 much of NETCONF still applies (getting/setting/locking datastores, 578 etc), some NETCONF operations are extended to allow passing the 579 device's native configuration format. Specifically, the RPC and RPC-reply are extended to support 581 passing an opaque payload. Naturally, subtree-filtering is 582 disabled for the operation. 584 o One of the devices that Juniper acquired has no notion of locking. 585 The goal of the acquisition was to import the device's technology 586 into Junos, but customers owning the original device wanted to 587 continue using their existing hardware. However, since it was 588 deemed impossible to add NETCONF to this device (not enough 589 resources), the NSM team was forced to develop a device adapter 590 that could mediate between the NETCONF interface the NMS system 591 requires and the CLI interface the device provided. The adapter 592 project was successful with one exception, the adapter had to 593 implement the / RPCs as null operations that blindly 594 returned . 596 Authors' Addresses 598 Vladislav Perelman 599 Jacobs University Bremen 601 EMail: v.perelman@jacobs-university.de 603 Juergen Schoenwaelder 604 Jacobs University Bremen 606 EMail: j.schoenwaelder@jacobs-university.de 608 Mehmet Ersue 609 Nokia Siemens Networks 611 EMail: mehmet.ersue@nsn.com 613 Kent Watsen 614 Juniper Networks 616 EMail: kwatsen@juniper.net