idnits 2.17.1 draft-nmdt-anima-management-bootstrap-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 : ---------------------------------------------------------------------------- ** There are 2 instances of too long lines in the document, the longest one being 35 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 26, 2018) is 2038 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) == Unused Reference: 'I-D.behringer-anima-reference-model' is defined on line 424, but no explicit reference was found in the text == Unused Reference: 'RFC7576' is defined on line 454, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2629 (Obsoleted by RFC 7749) == Outdated reference: A later version (-30) exists of draft-ietf-anima-autonomic-control-plane-18 Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group F. Duan 3 Internet-Draft B. Liu, Ed. 4 Intended status: Standards Track Y. Zhang 5 Expires: March 30, 2019 Huawei Technologies 6 September 26, 2018 8 Anima Bootstrapping for Network Management 9 draft-nmdt-anima-management-bootstrap-01 11 Abstract 13 This document points out the gaps of utilizing current Anima 14 technologies into a traditional centralized management network. It 15 raises some problems and requirments, based on which, as set of 16 solutions are proposed. (These solutions are called Anima 17 Bootstrapping for Network Management.) 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at https://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on March 30, 2019. 36 Copyright Notice 38 Copyright (c) 2018 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (https://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 3. Problems and Requirments . . . . . . . . . . . . . . . . . . 3 56 4. Autonomic Structured Naming . . . . . . . . . . . . . . . . . 4 57 4.1. Requirements . . . . . . . . . . . . . . . . . . . . . . 4 58 4.2. Name Format and Content . . . . . . . . . . . . . . . . . 5 59 4.2.1. Structured Naming Format . . . . . . . . . . . . . . 5 60 4.2.2. Naming Content . . . . . . . . . . . . . . . . . . . 5 61 4.3. Autonomic Naming Approaches . . . . . . . . . . . . . . . 6 62 4.3.1. Received and Self-generated Naming Elements . . . . . 6 63 4.3.2. Naming Metadata Storage . . . . . . . . . . . . . . . 7 64 5. Network Management Server/Controller Discovery . . . . . . . 7 65 5.1. GRASP Method . . . . . . . . . . . . . . . . . . . . . . 7 66 5.2. mDNS Method . . . . . . . . . . . . . . . . . . . . . . . 8 67 6. Topology Discovery and Collection . . . . . . . . . . . . . . 8 68 6.1. Local Topoloty Discovery . . . . . . . . . . . . . . . . 8 69 6.2. Topology Collection by NMS/Controller . . . . . . . . . . 9 70 7. Device Names and Topoloty Mapping in the NMS/Controller . . . 9 71 8. Security . . . . . . . . . . . . . . . . . . . . . . . . . . 9 72 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 73 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 74 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 75 11.1. Normative References . . . . . . . . . . . . . . . . . . 9 76 11.2. Informative References . . . . . . . . . . . . . . . . . 10 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 79 1. Introduction 81 One typical usage of ANIMA technologyies is that they serve as a 82 stable management channel of the management systems, such as 83 controllers or network management system (NMS) hosts. And These 84 cases is also described in section 6 of 85 [I-D.ietf-anima-autonomic-control-plane], with the purpose of 86 management and controllability of ACP for the controllers or NMS 87 hosts. However, In ANIMA networking, the autonomic nodes in ACP are 88 self configurable by default, most configuration of which is learning 89 from neighboring nodes in decentralized ways. While in traditional 90 networking, the configuration is got by the top-down ways from the 91 centralized devices (such as controller, NMS hosts etc) . These are 92 the gaps and differences between the traditional networking and ANIMA 93 networking. 95 Following this Introduction, Section 3 describes the problems of the 96 integration of ACP and traditional centralized netwoking nodes, and 97 then layout the solution requirments of it. 99 Based on the problems and solution requirments, this document 100 disscusses the Autonomic Structured Naming mechanism (in section 101 Section 4), which provids meaningful names easy for human operation 102 and maintanance; autonomc NMS/Controller discovery by the Autonomic 103 Nodes Section 5 ; and topology discovery and collection Section 6 104 allowing the NMS/Controller to learn the topology of the managed 105 network. Finally, dicusses the capability of NMS/Controller 106 correlating the naming and topology information to layout the whole 107 picture of the managed entities in the Anima domain. 109 2. Terminology 111 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 112 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 113 "OPTIONAL" in this document are to be interpreted as described in 114 [RFC2119] when they appear in ALL CAPS. When these words are not in 115 ALL CAPS (such as "should" or "Should"), they have their usual 116 English meanings, and are not to be interpreted as [RFC2119]key 117 words. 119 This document use the key words defined in [RFC7575] . 121 The following additional terms are used throughout this document: 123 o AN: Autonomic Nodes. 125 o NMS: Networking Management System. 127 o EMS: Element Management System. 129 o NE: Networking Element. 131 3. Problems and Requirments 133 In ANIMA networking, every autonomic node has a global unique 134 management address, this is the same with traditional networking. 135 However, in traditional networking, the management addresses are 136 globally planned by administrator. While in ANIMA networking, they 137 are locally defined by the autonomic node itself using the 138 information extracted from the domain certificate, called ULA 139 addresses, as described in the section 5.8.2 of 140 [I-D.ietf-anima-autonomic-control-plane]. In the view of centralized 141 management tools, such as Networking Management System (NMS) hosts, 142 there are usually two function modules included, the Element 143 Management System (EMS) and the NMS core. The EMS is created by 144 networking manager manually one by one for each networking element, 145 using globally planned management addresses to establish SNMP 146 sessions between EMS and networking elements. In ANIMA networking, 147 because of the local definition of ULA addresses, it is difficult for 148 networking managers to select which address to establish SNMP session 149 or to do a correct functional deployment for each device. 151 To resolve the problems raised above, the requirments listed 152 following must be satisfied: 154 o The autonomic nodes' physic location and functional roles in 155 networking MUST be initially setted before running and can be 156 dynamicly discoveried by the centralized management tools. 158 o The IP address of the centralized management tools MUST be 159 published as service in the ANIMA networking, so that the 160 autonomic nodes can trap the device information to the NMS host. 162 o By receiving the traps of the autonomic nodes, the centralized 163 management tools must create the corresponding EMS in autonomic 164 ways, not in manul ways by networking managers. 166 4. Autonomic Structured Naming 168 4.1. Requirements 170 - Representing each device 172 o Inside a domain, each autonomic device needs a domain specific 173 identifier. 175 - Uniqueness 177 o The names MUST NOT collide within one autonomic domain. 179 o It is acceptable that the names in different domains collide, 180 since they could be distinguished by domains. 182 - Semantic Encoding 184 o It is RECOMMENDED that the names encode some semantics rather than 185 meaningless strings. This is for ease of management consideration 186 that network administrators could easily recognize the device 187 directly through the names. 189 - Consistency 190 o The devices' naming SHOULD follow the same pattern within a 191 domain. 193 4.2. Name Format and Content 195 4.2.1. Structured Naming Format 197 - Naming Elements 199 The whole name string could be combined with several individual 200 Naming Elements, each of which representing a specific semantic. 201 For example: Location-DeviceType-FunctionalRole- 202 DistinguisherNumber@NameofDomain. 204 The structure should be flexible that some elements are optional. 205 When these optional fields are added, the name could still be 206 recognized as the previous one. 208 - Element Attributes 210 Each Naming Element could have zero or more attributes describing 211 detailed information of the element. The attributes do not need 212 to be presented in the naming string, but be stored as metadata in 213 the devices and be reported to the management system. 215 - Mandatory and Optional Naming Elements 217 In above example, the "DistinguisherNumber" and "NameofDomain" are 218 mandatory whereas others are optional. At initial stage, the 219 devices might be only capable of self-generating the mandatory 220 fields and the "DeviceType" because of the lack of knowledge. 221 Later, they might have learned the "Location" and "FunctionalRole" 222 and added the fields into current name. However, the other 223 devices could still recognize it according to the same 224 "DistinguisherNumber". 226 4.2.2. Naming Content 228 The naming information SHOULD be suitable for the centralized tools 229 to determine the location of the device and the functions to be 230 deployed. The composing parts of the naming information are listed 231 as following : 233 o Device Type 235 o Ownership 236 o Location. The physical location of the devices MUST be 237 abbreviated and abstracted, and usually be setted into the device 238 name feilds of the naming information. How to abbreviate and 239 abstract the location information, is a policy of the ISP and out- 240 of-scope of this document. 242 o Role and Function. The roles and the functions to be deployed in 243 the devices MUST be specified in high level words, and usually be 244 setted into the device function description feilds of the naming 245 information. It MUST NOT include any detailed configuration 246 parameters of the roles and functions. How to define the high 247 level words of each function and role is out-of-scope of this 248 document. 250 o TBD. 252 4.3. Autonomic Naming Approaches 254 4.3.1. Received and Self-generated Naming Elements 256 There are mainly two kinds of naming information, as the following. 258 - Received Naming Elements 260 The elements are advertised or injected by some external source. 261 Operators are responsible for provisioning this kind of information. 262 At least one of the interface types listed as following SHOULD be 263 supported by the Autonomic Network: 265 o Hardware interface. The operator uses some out-of-bind tools to 266 specify the naming information as a initiail configure file, and 267 write it to some storage material, such as USB devices, SD cards 268 and etc. The physical interfaces MUST be supported by the devices 269 to pluge in the storage materials. In the system starting up 270 procedure of the devices, it reads the naming information from the 271 initial setted configure file, and reports the relation of the ULA 272 addresses and device name to the centralized tools as described in 273 the following sections of this document. 275 o Software interface. During the first startup of the device 276 system, the operator uses some in-bind software interfaces (such 277 as Command Line Interface (CLI), Web Brower and etc) to specify 278 the naming information as a configure file, and to write it to its 279 internal storage material, such as FLASH cards. If there is no 280 naming information configure file, the starting procedure pauses 281 and wait for the configuration of the naming information. After 282 the configuration or if there is already an exsting naming 283 information file, the device continues the starting procedure, 284 reads out the naming information and reports the relation of the 285 ULA addresses and device name to the management tools as described 286 in the following sections of this document. 288 - Self-generated Naming Elements 290 The mandatory fields SHOULD be self-generated so that one device 291 could name itself sufficiently without any advertised knowledges. 293 There should various methods for a device to extract/generate a 294 proper word for each mandatory semantic fields (e.g. "DeviceType", 295 "DistinguisherNum") from its self-knowledge. 297 4.3.2. Naming Metadata Storage 299 TBD. 301 5. Network Management Server/Controller Discovery 303 In order to connect to the centralized management tool, the AN 304 devices MUST get acknowledgement of the address of it. In ANIMA 305 netwoking, this MUST be done in autonomic ways. This section 306 describes two methods for dynamic learning of the address of 307 centralized management tools. 309 5.1. GRASP Method 311 This method is mandatory in ANIMA networking. 313 A centralized management tool is typically configured manually. When 314 the centralized management tool joins an Autonomic Control Plane 315 ([I-D.ietf-anima-autonomic-control-plane]) it MUST respond to GRASP 316 ([I-D.ietf-anima-grasp]) M_NEG_SYN message. If the centralized 317 management tool dose not take part in the ACP, the IPV6 address MUST 318 be configured in one device (called Mangement Proxy) of ANIMA 319 networking and that AN device MUST be responsible for responding to 320 GRASP M_NEG_SYN message. 322 The discovery messages send from the AN devices to the centralized 323 management tool ( or Mangement Proxy) as follows: 325 discovery-message = [M_NEG_SYN, session-id, initiator, Centralized-tool-objective] 326 Centralized-tool-objective = ["AN_centralized_tool", F_SYNCH, loop-count, centralized-tool-address] 327 centralized-tool-address = ipv6-address 329 Figure 5: Centralized Management Tool Discovery 331 The value of centralized-tool-address field is zero. Other fields 332 are followed the specification of GRASP. 334 The response from the Centralized Management Tool (or Mangement 335 Proxy) will be a M_RESPONSE with the following parameters: 337 response-message = [M_RESPONSE, session-id, initiator, ttl, 338 (+locator-option // divert-option), Centralized-tool-objective)] 340 Figure 6: Centralized Management Tool Response 342 The value of centralized-tool-address field in Centralized-tool- 343 objective is zero. Other fields are followed the specification of 344 GRASP. 346 After the discovery precedure, the AN devices use M_REQ_SYN messages 347 and the Centralized Management Tool (or Mangement Proxy) responds 348 with M_SYNCH message as described in GRASP. In M_SYNCH message, the 349 Centralized Management Tool (or Mangement Proxy) filles the 350 centralized-tool-address field in Centralized-tool-objective of 351 M_SYNCH message with the valid IPV6 address of Centralized Tool. 353 5.2. mDNS Method 355 This method is optional in ANIMA networking. 357 Performs DNS-based Service Discovery [RFC6763] over Multicast DNS 358 [RFC6762] searching for the service 359 "_centralize_management_address.udp.local". To prevent unacceptable 360 levels of nework traffic the congestion avoidance mechanisms 361 specified in [RFC6762] section 7 MUST be followed. The AN devices 362 SHOULD listen for an unsolicited broadcast response as described in 363 [RFC6762]. This allows AN devices to avoid announcing their presence 364 via mDNS broadcasts and instead silently join the centralized 365 management tools by watching for periodic unsolicited broadcast res 367 6. Topology Discovery and Collection 369 6.1. Local Topoloty Discovery 371 For the traditional centralized tools such as NMS hosts, the Link 372 Layer Dicovery Protocol (LLDP) is used to dicovery the neigboring 373 nodes and the links between two nodes, this was specified in IEEE 374 802.1ab. 376 6.2. Topology Collection by NMS/Controller 378 GRASP is used to carry topology information to the NMS/Controller. 379 (Detailes TBD.) 381 7. Device Names and Topoloty Mapping in the NMS/Controller 383 There are two information types for the AN devices that must be 384 exchanged in ANIMA networking, So that the centralized management 385 tools can get the acknowgledgment of the topology of it. The fixed 386 information, which is the name of the AN devices, and were initially 387 setted by the operators in the setting up procedures as described in 388 the previous sections. The dynamic information, which is 389 autonomously created or learned by the AN devices themselves, 390 including the ULA addresses of the ACP, domain name of the neworking 391 and etc. 393 8. Security 395 TBD. 397 9. IANA Considerations 399 TBD. 401 10. Acknowledgements 403 The main idea of this document was initiated by Gang Yan. 405 Valuable comments were received from Sheng Jiang etc. 407 This document was produced using the xml2rfc tool [RFC2629]. 409 11. References 411 11.1. Normative References 413 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 414 Requirement Levels", BCP 14, RFC 2119, 415 DOI 10.17487/RFC2119, March 1997, 416 . 418 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 419 DOI 10.17487/RFC2629, June 1999, 420 . 422 11.2. Informative References 424 [I-D.behringer-anima-reference-model] 425 Behringer, M., Carpenter, B., Eckert, T., Ciavaglia, L., 426 Liu, B., Jeff, J., and J. Strassner, "A Reference Model 427 for Autonomic Networking", draft-behringer-anima- 428 reference-model-04 (work in progress), October 2015. 430 [I-D.ietf-anima-autonomic-control-plane] 431 Eckert, T., Behringer, M., and S. Bjarnason, "An Autonomic 432 Control Plane (ACP)", draft-ietf-anima-autonomic-control- 433 plane-18 (work in progress), August 2018. 435 [I-D.ietf-anima-grasp] 436 Bormann, C., Carpenter, B., and B. Liu, "A Generic 437 Autonomic Signaling Protocol (GRASP)", draft-ietf-anima- 438 grasp-15 (work in progress), July 2017. 440 [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, 441 DOI 10.17487/RFC6762, February 2013, 442 . 444 [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service 445 Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, 446 . 448 [RFC7575] Behringer, M., Pritikin, M., Bjarnason, S., Clemm, A., 449 Carpenter, B., Jiang, S., and L. Ciavaglia, "Autonomic 450 Networking: Definitions and Design Goals", RFC 7575, 451 DOI 10.17487/RFC7575, June 2015, 452 . 454 [RFC7576] Jiang, S., Carpenter, B., and M. Behringer, "General Gap 455 Analysis for Autonomic Networking", RFC 7576, 456 DOI 10.17487/RFC7576, June 2015, 457 . 459 Authors' Addresses 461 Fanghong Duan 462 Huawei Technologies 463 N8, Huawei Campus 464 No. 101 Ruanjian Road 465 Yu-Hua-Tai District, Nanjing 210000 466 P.R. China 468 Email: duanfanghong@huawei.com 469 Bing Liu (editor) 470 Huawei Technologies 471 Q14, Huawei Campus 472 No.156 Beiqing Road 473 Hai-Dian District, Beijing 100095 474 P.R. China 476 Email: leo.liubing@huawei.com 478 Yongkang Zhang 479 Huawei Technologies 480 N8, Huawei Campus 481 No. 101 Ruanjian Road 482 Yu-Hua-Tai District, Nanjing 210000 483 P.R. China 485 Email: zhangyongkang@huawei.com