Network Management Rearch Group D. Bogdanovic Internet-Draft X. Liu Intended status: Informational Volta Networks Expires: 4 May 2021 L.M. Contreras Telefonica 31 October 2020 Multilevel configuration draft-bogdanovic-multilevel-configuration-00 Abstract This document describes issues caused by residual configurations in network devices and how multi-level configuration could potentially offer a solution. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 4 May 2021. Copyright Notice Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Bogdanovic, et al. Expires 4 May 2021 [Page 1] Internet-Draft multilevel configs October 2020 Table of Contents 1. Definitions and Acronyms . . . . . . . . . . . . . . . . . . 2 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 3. Use cases . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3.1. Service assurance . . . . . . . . . . . . . . . . . . . . 3 3.2. Network migrations and mergings . . . . . . . . . . . . . 3 3.3. Network slicing . . . . . . . . . . . . . . . . . . . . . 4 3.4. Zero touch provisioning . . . . . . . . . . . . . . . . . 4 4. Security Considerations . . . . . . . . . . . . . . . . . . . 4 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 4 7. Change log [RFC Editor: Please remove] . . . . . . . . . . . 4 8. Informative References . . . . . . . . . . . . . . . . . . . 4 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5 1. Definitions and Acronyms TCAM: Ternary Content Addressable Memory 2. Introduction As network operators experience traffic and customer growth, the network device configurations are getting larger. All the config information, both network operator and customers, on the device is multiplexed into single file and the configuration differentiation belonging to different owners becomes harder. This leads to the operators not knowing why certain parts of the config are in the file. Another issue contributing to config growth are debugging sessions. Network operator enters the device and starts editing configuration. After the debug session is finnished, it is not unusual for debug configuration entries to stay in the config file indefinitely. In order to solve this problem, some operators created central database with all the network configuration files that act as systems of record. If anything is to persist on the device in the network, it has to be in the central database. Still, this solution has not remedided the problem. Both, vendors and operators, contribute to the problem: * Vendors by keeping the configuration file structures as currently designed; * Operators by allowing human operator to directly edit config file on the device. Bogdanovic, et al. Expires 4 May 2021 [Page 2] Internet-Draft multilevel configs October 2020 Until the above two issues are solved, the residual configuration problem will persist and continue to waste expensive data plane resources (TCAM). This draft authors are motivated to propose a solution from both sides, operator and vendor. Our initial idea is to keep the persistent configuration at minimum on the device. All network service configurations are generated on demand and are ephemeral. This requires a change to the config file structure, creating multi- level file structure with dependencies between different levels.Besides the residual configuration problem, there are other use cases that multi-level configuration can be applied, that are listed in this document. 3. Use cases 3.1. Service assurance Service assurance is one of the critical operational aspects of the communication networks. As [I-D.claise-opsawg-service-assurance-architecture] states, services rely on multiple sub-services on top of the same underlying network, then service affection on any of those sub-services can propagate impacts to many other services in the network. In this respect, the multi-level network configuration approach could help on identifying by design the correlation among services and atomic functions in the network, simplifying the operation and providing a uniform framework across networks. 3.2. Network migrations and mergings Quite often service providers get involved in complex procedures of network mergings or migrations. Either driven by simplification of existing networks, introduction of new services, rationalization of multiple infrastructures, acquisition of other providers, etc., all of them imply both the introduction and removal of distinct configurations of multiple purposes. Apart of the complexity and difficulty of converging to a common and unique approach, these procedures could impact service continuity. In this sense, multi- level network configuration could highly simplify the process. First, by dividing the problem in smaller pieces, dealing with the issue per configuration level instead of considering the whole configuration. And second, by allowing incremental execution of the process by acting on particular levels each time. Bogdanovic, et al. Expires 4 May 2021 [Page 3] Internet-Draft multilevel configs October 2020 3.3. Network slicing Network slices are expected to provide tailored networks that can accommodate services with specific characteristics and service level objectives (SLOs) [I-D.nsdt-teas-ietf-network-slice-definition]. In this respect, the multi-level network configuration approach can be leveraged as a mean for deploying particular IETF network slices, facilitating the instantiation, operation and decommissioning of the slice in a straightforward manner. 3.4. Zero touch provisioning [RFC8886] proposes a mechanism for remotely auto-installing configurations on network devices with proper confidentiality and security. Such mechanism is conceived for receiving initial configuration by the device, for a later completion of the configuration by other means. In this case, leveraging on multi- level network configuration could permit incremental deployment of configuration levels following a similar auto-installing approach, according to some configuration workflow as defined by the service provider. 4. Security Considerations TBD 5. IANA Considerations This document currently has no items for IANA considerations. 6. Acknowledgements 7. Change log [RFC Editor: Please remove] 8. Informative References [I-D.claise-opsawg-service-assurance-architecture] Claise, B., Quilbeuf, J., Fathi, Y., Lopez, D., and D. Voyer, "Service Assurance for Intent-based Networking Architecture", Work in Progress, Internet-Draft, draft- claise-opsawg-service-assurance-architecture-03, 27 July 2020, . Bogdanovic, et al. Expires 4 May 2021 [Page 4] Internet-Draft multilevel configs October 2020 [I-D.nsdt-teas-ietf-network-slice-definition] Rokui, R., Homma, S., Makhijani, K., Contreras, L., and J. Tantsura, "Definition of IETF Network Slices", Work in Progress, Internet-Draft, draft-nsdt-teas-ietf-network- slice-definition-00, 21 October 2020, . [RFC8886] Kumari, W. and C. Doyle, "Secure Device Install", RFC 8886, DOI 10.17487/RFC8886, September 2020, . Authors' Addresses Dean Bogdanovic Volta Networks Email: dean@voltanet.io Xufeng Liu Volta Networks Email: xufeng@voltant.io Luis M. Contreras Telefonica Email: luismiguel.contrerasmurillo@telefonica.com Bogdanovic, et al. Expires 4 May 2021 [Page 5]