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, <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]