idnits 2.17.1 draft-teramoto-experience-network-management-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 (Feb 26, 2013) is 4070 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Y. Teramoto 3 Internet-Draft Kyoto University 4 Intended status: Informational R. Atarashi 5 Expires: August 30, 2013 IIJ Research Laboratory 6 Y. Atarashi 7 Alaxala Networks Corp. 8 Y. Okabe 9 Kyoto University 10 Feb 26, 2013 12 Experience of Designing Network Management System 13 draft-teramoto-experience-network-management-01 15 Abstract 17 This document describes our experiences from designing and 18 implementing a large-scale local area network management system using 19 mainly NETCONF. We designed the data models for device 20 configurations and implemented NETCONF client to centrally control 21 multiple devices of various vendors. The document provides insight 22 on strong and weak points of current NETCONF approach. The document 23 also makes some recommendations about NETCONF and future network 24 management protocols. 26 Status of this Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on August 30, 2013. 43 Copyright Notice 45 Copyright (c) 2013 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2. Management System Setup . . . . . . . . . . . . . . . . . . . . 3 62 2.1. Required Information . . . . . . . . . . . . . . . . . . . 3 63 3. Experiences of Implementing NETCONF Client . . . . . . . . . . 4 64 3.1. Transport Protocol . . . . . . . . . . . . . . . . . . . . 4 65 3.2. Framing Mechanism on SSH transport . . . . . . . . . . . . 5 66 3.3. Capability Exchange . . . . . . . . . . . . . . . . . . . . 5 67 3.4. Lock and Commit Mechanism . . . . . . . . . . . . . . . . . 6 68 3.5. Notification . . . . . . . . . . . . . . . . . . . . . . . 6 69 4. Experiences with Data Model Design . . . . . . . . . . . . . . 7 70 4.1. YANG . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 71 5. Experiences with Management Network . . . . . . . . . . . . . . 7 72 5.1. VLAN Configuration . . . . . . . . . . . . . . . . . . . . 7 73 6. Conclusions and Recommendations . . . . . . . . . . . . . . . . 8 74 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 9 75 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 9 76 9. Normative References . . . . . . . . . . . . . . . . . . . . . 9 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 79 1. Introduction 81 We designed a large-scale local area network management system that 82 can manage the network independently of physical topology and the 83 vendor of networking equipments composing the network system by 84 modeling the functions of network equipments and using widely used 85 network management protocols. To manage networks, we used mainly the 86 NETCONF protocol and the SNMP [RFC3416] because these protocols are 87 supported by various major vendors' networking equipments and does 88 not depend on specific architectures such as an OpenFlow or a MPLS. 89 This document describes the experiences from designing and 90 implementing such management system. 92 An NETCONF protocol is defined in [RFC6241] and is intended to manage 93 configurations of the networking equipment from computers. The 94 NETCONF protocol is supported by various network equipments such as 95 Cisco IOS and Junos and so on. We mainly used a NETCONF protocol to 96 get and edit configurations of networking equipments. Although many 97 networking equipments support the NETCONF protocol, there are some 98 kinds of data model designed by vendors. It is because the model 99 layer of NETCONF protocol is still developing. We designed the 100 unified data model for device configurations to manage multiple 101 equipments of various vendors and implemented NETCONF client to 102 control multiple devices simultaneously. 104 This document evaluates the NETCONF protocol design and makes some 105 recommendations about NETCONF and future network management protocols 106 to support large-scale network management. 108 2. Management System Setup 110 Our Network management system contains some information in database 111 to grasp network states and authorize management interface of 112 equipments. The NETCONF protocol and SNMP requires login 113 authorization on starting login. Moreover these protocols support 114 only the information for the configurations and states, and hence the 115 management system needs some information related to several 116 networking equipments such as the network topology and the routes of 117 IP packets. The remainder of this section describes the setup 118 information that is required to start network managing. 120 2.1. Required Information 122 Network Management systems usually require some information in 123 advance that the systems cannot retrieve from network devices 124 automatically like followings: 126 Management Interface 128 One of the most fundamental information is login authorization for 129 connecting to management interfaces of network devices: management 130 IP address, user ID, password and so on. This is because 131 management protocols such as NETCONF and SNMP usually requires 132 authentication to get or edit device configurations at need to be 133 secured. 135 Device Information 137 The system requires the information for devices, such as the 138 vendor, the model and the version to determine the capabilities 139 and providing resource of the device, because NETCONF provides no 140 information and no unified models for them. 142 Network Information 144 Network Devices provides no information for network topology. 145 There are some protocols to get neighbor information such as LLDP, 146 however there is no standardized protocols to provide them into 147 client. Therefore, to manage network with network topology, the 148 topology information is to be prepared in advance. 150 3. Experiences of Implementing NETCONF Client 152 The NETCONF protocol is an XML-based protocol used to manage the 153 configuration of networking equipment. We implemented NETCONF client 154 to manage networking equipments centrally. This section provides 155 insight on NETCONF protocol. 157 3.1. Transport Protocol 159 The NETCONF protocol defines an SSH protocol as mandatory transport 160 protocol. The advantage of using the SSH protocol is that it 161 provides strong authentication mechanism and full encrypted 162 communication. However, there are some issues of using the SSH 163 protocol. It is very large protocol for developers to implement full 164 scratch client, therefore they need to use some existing libraries. 165 Network management systems often have their own architecture for 166 increasing performance, because it is often required high-performance 167 operation and response. SSH libraries also often have their own 168 architecture, and hence it is need to carefully bond two 169 architecture. This may cause performance degradation on multi- 170 threading software because these asynchronous events cannot be 171 concentrated into one. Furthermore, if encrypted communication is 172 forced like the SSH protocol, it is sometimes difficult to detect the 173 cause of transport problems on debugging. 175 3.2. Framing Mechanism on SSH transport 177 The current framing mechanism of SSH transport is defined in 178 [RFC6242]. The previous version of NETCONF (version 1.0) defined 179 framing mechanism to separate each messages by the character sequence 180 "]]>]]>" according to the assumption that well-formed XML documents 181 does not contain the sequence, however it was found later that the 182 assumption is not collect. Therefore the current framing mechanism 183 of SSH uses chunked framing mechanism. 185 However framing mechanism still have confusing specification. The 186 framing mechanism defines no error notification mechanism when given 187 chunk-size is invalid or an error occurs on transport layer. 188 [RFC6242] requires the peer to terminate the NETCONF session 189 immediately without notifying error information when receiving such 190 an invalid message. This mechanism often causes confusing issues 191 that the developer cannot determine the reason of unexpected 192 disconnection, because the reason may exist on multiple layers from 193 physical layer to application layer. This problem also occurs on the 194 previous version. 196 3.3. Capability Exchange 198 Capabilities are advertised in messages sent by each peer during 199 session establishment as message. Each peer determines the 200 NETCONF version by comparing the sent capabilities with received one. 201 Furthermore this list can contain other additional capabilities such 202 as the capability of notification. 204 The mechanism of capability exchange have the same undesirable 205 specification as framing mechanism of the SSH transport. [RFC6241] 206 require peers to disconnect the session immediately when the 207 supporting capability version is mismatched or the treatment of 208 session-id is wrong. 210 The reaction of invalid varies by vendor implementations. 211 For example, the Junos returns error message as XML comments like 212 followings: 213 214 216 Cisco IOS returns no error message and disconnected on receiving next 217 message by the frame chunk. This causes unexpected disconnection on 218 sending first command. 220 This is notable that other management protocols that have capability 221 exchange such as OpenFlow often support error notification mechanism 222 on receiving an invalid hello message. 224 3.4. Lock and Commit Mechanism 226 Lock mechanism of NETCONF is defined in [RFC6242] as mandatory 227 function. Commit mechanism is defined as optional function. These 228 commands are useful on controlling multiple devices. 230 3.5. Notification 232 The original NETCONF protocols does not provide networking equipments 233 to push some information to client. To send some information from 234 servers, notification mechanism is defined as optional capability in 235 [RFC5277]. 237 Notification mechanism supports replaying the previous logs by 238 specifying startTime. After starting notification, the server can 239 only operate close-session command to terminate current session and 240 returns resource-denied error on receiving other commands. However, 241 the server that supports interleave capability can operate any 242 commands while notification phase. The client can specify stopTime 243 to stop the notification on the time. After stop time, NETCONF 244 session becomes ordinal mode and accept any NETCONF commands again. 246 This too complicated mechanism makes enormous number of session 247 states and conditions like following diagram; this makes it difficult 248 to create brief management system that support full NETCONF 249 specifications. 251 +-------+ 252 | Hello | 253 +-------+ 254 | exchange 255 S +-------+ <------+ 256 t+>| RPC | | return result 257 o| +-------+ -------+ 258 p| | 259 T| |<--------------------------+ Yes: return result 260 i| +--------+ ----------- | No : return resource-denied 261 m+-| Notify |------< interleave? >-+ 262 e +--------+ ----------- 263 | 264 End 266 Figure 1: Session States and Conditions 268 4. Experiences with Data Model Design 270 Current NETCONF protocol does not provide data models specification, 271 and hence there is no unified data models. Therefore, to manage 272 networking equipments of multiple vendors with same way, we designed 273 some models of the function that networking equipments provides. 274 This section describes the insight on current approach of 275 standardizing data models. 277 4.1. YANG 279 YANG is a data modeling language used to model configuration and 280 state data manipulated by the NETCONF defined in [RFC6020]. The 281 approach of YANG is to express various configurations using highly 282 expressive schema, while the approach of SNMP is to predefine 283 fundamental data model. 285 The same approaches of YANG often causes variability of configuration 286 model and also causes too large and complex data schema. Furthermore 287 YANG defines only the model schema, therefore the way to construct 288 model data is owed to the developer. We think the fundamental model 289 data, that is frequently used in configuration such as VLANs and 290 Interfaces, should be defined by NETCONF core specification like SNMP 291 in order to avoid such problems. 293 5. Experiences with Management Network 295 We designed the system to manage multiple network equipments of 296 multiple vendors that support the NETCONF protocol. This section 297 describes the experience with example of designing some function that 298 uses multiple networking equipments via NETCONF. 300 5.1. VLAN Configuration 302 VLAN configuration is one of most fundamental functions; however the 303 configuration needs various information. VLAN configuration requires 304 following information: 306 o Current VLAN assignment 308 o VLAN ID and port name to be assigned 310 o Additional information such as bandwidth, port state (some ports 311 may be disabled) 313 o Network topology 314 First two information can be retrieved from NETCONF configurations. 315 The rest information, however, is more difficult than the former two. 316 NETCONF provides no information for the capability of networking 317 equipments, such as ports speed or the number of ports, that is not 318 shown as configuration text. NETCONF also does not offer topology or 319 neighbor information because of the same reason. 321 No current widely used protocols support the mechanism to retrieve 322 such information, therefore we have no choice but prepare them in 323 advance. However, an OpenFlow protocol now provide the way to get 324 them by handling LLDP packets using packet-out operation. This is 325 one of the reasons that an OpenFlow protocol is referred as a hot 326 protocol. 328 6. Conclusions and Recommendations 330 We come to deeply know about the NETCONF protocol on the view of 331 developers. This section conclude our experience and recommends some 332 requirements that future management protocol would satisfy. 334 The current NETCONF protocol have some undesirable specifications 335 like followings: 337 o Specify an SSH protocol as an mandatory transport protocol. 339 o Some undesirable error handling such as on capability exchange 340 failure 342 o Too many state and conditions of each session by notification 344 Furthermore, a current approach of models is going toward complicated 345 and large models by YANG. We propose future management protocols to 346 use simple transport protocol, to define appropriate error handling 347 that does not disconnect without any error notification, and to 348 provide simple notification mechanism that is supported by default 349 and supports interleave capability like function as default. 351 Current Network Management is required to use some similar protocols 352 such as NETCONF and SNMP. We found that the two protocol is covering 353 each other weakness that NETCONF does not support live information 354 and SNMP does not support configuration management. However, there 355 are few ways to get the capability of the networking equipments and 356 the information for constructing topology graphs. There are often 357 required to prepared in advance. There is a need to new management 358 protocols for flexibly control whole network by providing appropriate 359 models and information of the network. 361 7. Security Considerations 363 In our experience, the NETCONF protocol require high security 364 considerations on the specification such as authorization and 365 encrypted messaging; therefore the use of the NETCONF protocol 366 improves the security of management. 368 To manage networking equipments centarally does not matter security 369 issues if they are used in separated logical network and operated 370 proper properly. 372 8. IANA Considerations 374 This document makes no request of IANA. 376 9. Normative References 378 [RFC3416] Presuhn, R., "Version 2 of the Protocol Operations for the 379 Simple Network Management Protocol (SNMP)", STD 62, 380 RFC 3416, December 2002. 382 [RFC5277] Chisholm, S. and H. Trevino, "NETCONF Event 383 Notifications", RFC 5277, July 2008. 385 [RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the 386 Network Configuration Protocol (NETCONF)", RFC 6020, 387 October 2010. 389 [RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A. 390 Bierman, "Network Configuration Protocol (NETCONF)", 391 RFC 6241, June 2011. 393 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 394 Shell (SSH)", RFC 6242, June 2011. 396 Authors' Addresses 398 Yasuhiro Teramoto 399 Graduate School of Informatics Kyoto University 400 Yoshida-Hommachi 401 Sakyo-ku, Kyoto 606-8501 402 Japan 404 Phone: +81-75-753-7417 405 Fax: +81-75-753-7440 406 Email: teramoto@net.ist.i.kyoto-u.ac.jp 408 Ray S. Atarashi 409 IIJ Research Laboratory 410 Jinbocho Mitsui Bldg., 1-105 Kanda Jinbo-cho 411 Chiyoda-ku, Tokyo 101-0051 412 Japan 414 Phone: +81-3-5205-6464 415 Fax: +81-3-5205-6466 416 Email: ray@iijlab.net 418 Yoshifumi Atarashi 419 Alaxala Networks Corp. 420 Shin-Kawasaki Mitsui Bldg. 421 890 Saiwai-ku Kashimada 422 Kawasaki, Kanagawa 212-0058 423 Japan 425 Phone: +81-44-549-1735 426 Fax: +81-44-549-1272 427 Email: atarashi@alaxala.net 429 Yasuo Okabe 430 Academic Center for Computing and Media Studies Kyoto-University 431 Yoshida-Hommachi 432 Sakyo-ku, Kyoto 606-8501 433 Japan 435 Phone: +81-44-549-1735 436 Fax: +81-44-549-1272 437 Email: okabe@i.kyoto-u.ac.jp