Internet DRAFT - draft-bogdanovic-multilevel-configuration

draft-bogdanovic-multilevel-configuration







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]