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-00Abstract
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 Contents1. 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. Until the above two issues are solved, the residual configuration problem will persist and continue to waste expensive data plane resources (TCAM).
Bogdanovic, et al. Expires 4 May 2021 [Page 2]
Internet-Draft multilevel configs October 2020
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 assuranceService 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 slicingNetwork 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, <http://www.ietf.org/internet-drafts/draft-claise- opsawg-service-assurance-architecture-03.txt>.
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, <http://www.ietf.org/internet-drafts/draft-nsdt-teas-ietf- network-slice-definition-00.txt>.
[RFC8886] Kumari, W. and C. Doyle, "Secure Device Install",
RFC 8886, DOI 10.17487/RFC8886, September 2020, <https://www.rfc-editor.org/info/rfc8886>.
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]
