<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="yes"?>
<rfc category="info"
     docName="draft-boucadair-network-automation-requirements-05"
     ipr="trust200902" updates="">
  <front>
    <title abbrev="Requirements for Network Automation">Requirements for
    Automated (Configuration) Management</title>

    <author fullname="Mohamed Boucadair" initials="M." surname="Boucadair">
      <organization>France Telecom</organization>

      <address>
        <postal>
          <street></street>

          <city>Rennes</city>

          <region></region>

          <code>35000</code>

          <country>France</country>
        </postal>

        <email>mohamed.boucadair@orange.com</email>
      </address>
    </author>

    <author fullname="Christian Jacquenet" initials="C." surname="Jacquenet">
      <organization>France Telecom</organization>

      <address>
        <postal>
          <street></street>

          <city>Rennes</city>

          <region></region>

          <code>35000</code>

          <country>France</country>
        </postal>

        <email>christian.jacquenet@orange.com</email>
      </address>
    </author>

    <author fullname="Luis M. Contreras" initials="L." surname="Contreras">
      <organization>Telefonica I+D</organization>

      <address>
        <postal>
          <street>Ronda de la Comunicacion, s/n</street>

          <city>Madrid</city>

          <region></region>

          <code>28050</code>

          <country>Spain</country>
        </postal>

        <phone></phone>

        <facsimile></facsimile>

        <email>lmcm@tid.es</email>

        <uri>http://people.tid.es/LuisM.Contreras/</uri>
      </address>
    </author>

    <date day="" month="" year="2015" />

    <abstract>
      <t>Given the ever-increasing complexity of the configuration tasks
      required for the dynamic provisioning of IP networks and services, this
      document aims at listing the requirements for an automated configuration
      management framework.</t>
    </abstract>
  </front>

  <middle>
    <section title="Introduction">
      <t>IP network and service configuration procedures are currently handled
      by skilled personnel who is often required to acquire a high level of
      expertise that grows as the variety and the complexity of the services
      to be delivered over an IP network. This demand for a high level of
      expertise is further increased by heterogeneous network and service
      environments where each equipment manufacturer has developed its own
      proprietary interfaces and configuration schemes. As a consequence, the
      time to deliver complex yet advanced IP service offerings (such as IP
      TV, VPN, etc.) is also increasing at the risk of jeopardizing customers'
      quality of experience.</t>

      <t>This document advocates for the need to undertake a standardization
      effort to define an automated provisioning framework that includes a set
      of interfaces and protocol(s) for conveying configuration information
      which should help in facilitating the automation of the network resource
      allocation and service delivery procedures. Defining standard data and
      information models <xref target="RFC3444"></xref> to capture offered
      network services would help to automate the process of service ordering
      and activation and therefore accelerating service provisioning.</t>

      <t>Automation should not be targeted at dynamically enforcing policies
      only, but also be encouraged to:<list style="symbols">
          <t>Generate policy-related and configuration data based on a
          well-defined set of triggers and events.</t>

          <t>Monitor the outcome of a configured function/device to assess
          whether the observed behavior is aligned with the expected
          behavior.</t>
        </list></t>

      <t>This document assumes that service differentiation at the network
      layer can be enforced by tweaking various parameters which belong to
      distinct dimensions (e.g, forwarding, routing, traffic access
      management, traffic classification, etc.). As such, the decision point
      is likely to interact with several engines (e.g., routing engine,
      forwarding engine, etc.). In particular, this document considers that an
      I2RS system can be seen as a subset of an overall framework. I2RS is
      limited to routing and forwarding actions (see <xref
      target="forwarding"></xref>). To meet performance requirements (see
      <xref target="perf"></xref>), it is encouraged to design a system which
      interacts directly with the routing and forwarding system, rather than
      requiring local proxy functions which are responsible for translating
      vendor-independent commands and policies into vendor-specific
      configuration commands and syntax.</t>

      <t>In addition to protocol-related considerations, automating network
      operations heavily relies upon the availability of intelligent policy
      decision points. Sharing best design practices for policy decision point
      logics would facilitate the adoption of the proposed approach (see <xref
      target="service-driven"></xref>).</t>

      <t>The document enumerates a set of encountered issues (see <xref
      target="issues"></xref>) and identifies a set of requirements (see <xref
      target="reqs"></xref>). A service-driven approach is purposed in <xref
      target="service-driven"></xref>.</t>
    </section>

    <section title="Terminology">
      <t>This document makes use of the following terms: <list style="symbols">
          <t>Decision point: is an entity that is responsible for making
          decisions that yield the production of configuration information
          which will be conveyed towards (and processed by) the set of
          relevant managed entities.</t>

          <t>Managed entity: any (networking) device that will participate in
          the establishment, the activation and the maintenance of a given
          service. Such devices MAY include routers and terminals, whatever
          the configuration procedures and underlying technologies to be used
          for the delivery of the said service.</t>
        </list></t>
    </section>

    <section title="Scope &amp; Overall Context">
      <t>Maintain and operate self-adaptive networks may be seen as a long
      term objective for IP service providers. To achieve this goal,
      intermediate objectives should be defined, such as:<list style="numbers">
          <t>Define a framework to expose IP connectivity services to external
          parties, including peering IP network operators, content providers,
          services relying on connectivity services (e.g., IP TV, VoIP) (see
          for example <xref target="RFC7297"></xref>).</t>

          <t>Ability to automatically translate IP connectivity requirements
          into configuration and provision actions.</t>

          <t>Dynamically adapt service configuration to be aligned with
          expected service objectives.</t>

          <t>Automate service negotiation and service activation (e.g., <xref
          target="I-D.boucadair-connectivity-provisioning-protocol"></xref>).</t>

          <t>Optimize resource utilization, e.g., automatically set traffic
          engineering objectives.</t>
        </list></t>

      <t>Discussing the items above is out of scope. This document only
      discusses requirements for (automated) configuration procedures and
      protocol.</t>
    </section>

    <section title="Motivations">
      <t>Service providers and network operators have gained experience in
      implementing, deploying and manipulating a large set of protocols and
      associated information. Some data models have also been defined for
      network management purposes. Thus, several protocols have been
      standardized, such as SNMP (Simple Network Management Protocol <xref
      target="RFC3410"></xref>), COPS (Common Open Policy Service <xref
      target="RFC2748"></xref>), (COPS-PR <xref target="RFC3084"></xref>) or,
      more recently, NETCONF <xref target="RFC6241"></xref>.</t>

      <t>In addition, multiple data models have been defined and used by
      operators like CIM (Core Information Model), DEN (Directory-Enabled
      Network), SMI (Structure of Management Information <xref
      target="RFC2578"></xref>), SPPI (Structure of Policy Provisioning
      Information <xref target="RFC3159"></xref>), and, more recently, YANG
      <xref target="RFC6022"></xref>.</t>

      <t>Despite this standardization effort, most of the service operators
      still assume manual configuration through proprietary CLI (Command Line
      Interface) commands possibly combined with in-house developed,
      vendor-specific scripts to proceed with the configuration of numerous
      features, such as forwarding and routing capabilities, Quality of
      Service (sometimes including traffic engineering) capabilities, and
      security capabilities. Some of these requirements are fulfilled by
      existing tools/protocols but there is still a lack of wide adoption of
      those tools.</t>

      <t>Other non-technological challenges are also to be taken into
      consideration when discussing network automation (e.g., to what extent
      an automated system will accommodate both simple and complex business
      scenarios, how an automated system will evolve to accommodate changes
      and new procedures, assess the impact on testing
      methodologies,etc.).</t>

      <t>The purpose of this document is to document requirements rather than
      focusing on the non-technological challenges.</t>
    </section>

    <section anchor="issues" title="Issues Raised by Configuration Operations">
      <t>The following sub-sections enumerates a set of issues.</t>

      <section title="Heterogeneous Environments">
        <t>The delivery of IP services relies upon the activation of a set of
        capabilities located in various devices that include routers,
        switches, service platforms, etc. In particular, a large set of
        protocols need to be configured, such as routing protocols, management
        protocols, security protocols, let alone capabilities that relate to
        addressing scheme management, policy enforcement, etc.</t>

        <t>Such a diversity of features and protocols may increase the risk of
        inconsistency at the cost of QoS degradation or even service
        disruption. Therefore, the configuration information which is
        forwarded to the whole set of participating devices for delivering a
        given service or a set of services should be consistent, whatever the
        number of features/services to be activated/deployed in the
        network.</t>
      </section>

      <section title="Complex Topologies">
        <t>Network operators should have means to dynamically discover the
        topology of the network.</t>

        <t>Such topological information should be as elaborate as possible,
        including details like the links that connect network devices, their
        capacity, such as the total bandwidth, the available bandwidth, the
        bandwidth that can be reserved, etc.</t>
      </section>

      <section title="Multi-Functional Devices">
        <t>Numerous, often multi-vendor devices are involved in the delivery
        of IP services. These devices support various capabilities that need
        to be combined for the delivery of a given service or a set of
        services. The availability and status of such capabilities is
        therefore a critical information for service providers, since it is
        likely to affect service and network design, let alone operational
        procedures.</t>

        <t>Therefore, service providers and network operators should have
        means to:</t>

        <t><list style="symbols">
            <t>Dynamically retrieve, list and classify the capabilities
            supported by a given device (or a set thereof),</t>

            <t>Dynamically acquire detailed information about the availability
            and status of any activated capability of any device at any given
            time.</t>

            <t>Dynamically retrieve the version of embedded software modules,
            interfaces, OS version, etc.</t>
          </list></t>
      </section>

      <section title="Performance Impacts">
        <t>Configuring a set of devices to deliver a service takes time. In
        addition, depending on the complexity of the service, erroneous
        configurations may occur at the cost of jeopardizing the overall
        quality of a service, if not causing service disruption. From this
        perspective, some performance indicators must be defined and measured
        to assess: <list style="symbols">
            <t>The time to deliver a service, from subscription to operation.
            Such indicator may be further decomposed into elementary
            performance metrics, e.g., the time it takes to complete the
            configurations tasks that are specific to the enforcement of a
            given policy (forwarding, routing, QoS, etc.)</t>

            <t>The impact of any configuration change on the overall service
            performance (including customer's own perception).</t>
          </list></t>

        <t>Tools to qualify (by simulation or emulation) any possible impact
        of an elementary configuration task before such task is performed
        should be supported. These tools aims to prevent errors
        amplification.</t>
      </section>

      <section title="Scalability">
        <t>As far as scalability is concerned, adequate indicators should be
        specified in order to assess the ability of configuration techniques
        and protocols to support a large number of simultaneous processes. The
        maintenance of these processes should not impact the performance of
        the configuration system as a whole (i.e., manager and managed
        entities, amount of configuration task-specific traffic exchanged
        between manager and managed entities, periodicity of configuration
        operations, etc.).</t>

        <t>Therefore, configuration operations should be qualified with
        performance indicators in order to check whether the architecture
        designed for configuration management is scalable in terms of: <list
            style="symbols">
            <t>Amount of configuration data to be processed per unit of time,
            as a function of the number and the nature of the capabilities and
            devices that need to be configured.</t>

            <t>Amount of traffic generated by any reporting mechanism that may
            be associated to a configuration process.</t>

            <t>Number of processes that are created in order to achieve
            specific configuration operations.</t>
          </list></t>
      </section>

      <section title="Limits of Manual Configuration">
        <t>Manual configuration is not only a likely source of errors, but it
        also affects the time it takes to complete a configuration task (or a
        combination thereof) to deliver a service, as a function of the task
        complexity and the need for global consistency. Thus, the efficiency
        of a configuration process is likely to be improved by the
        introduction of a high level of automation. Automation is defined as
        follows:</t>

        <t><list style="symbols">
            <t>Automatic provisioning of configuration information to the
            participating devices.</t>

            <t>Dynamic enforcement of policies (possibly based upon the use of
            dynamic resource allocation techniques).</t>

            <t>Dynamic reporting mechanisms to notify about the actual
            processing of configuration information by a participating
            device.</t>

            <t>Autonomic provisioning capabilities for triggering
            self-configuration mechanisms for the network devices.</t>
          </list>Refer to Section 4.1 of <xref target="RFC7149"></xref> for a
        discussion on the implications of full automation.</t>
      </section>

      <section title="Security Issues">
        <t>Configuring a network or a service raises several security issues,
        including (but not limited to):<list style="symbols">
            <t>The integrity of the configuration information, possibly
            yielding the preservation of the confidentiality of such
            information when being forwarded over a public IP
            infrastructure,</t>

            <t>The need for authorizing and authenticating devices/entities
            that have the ability of manipulating configuration information
            (define, instantiate, forward and process),</t>

            <t>Mutual authentication between manager and managed entities.</t>
          </list></t>
      </section>
    </section>

    <section anchor="service-driven"
             title="Introducing Service-Driven Configuration Management">
      <t>Current practice consists in configuring elementary functions, i.e.,
      configuration management for a given service offering is decomposed into
      a set of elementary tasks. Thus, the consistency of configuration
      operations for the sake of service delivery must be checked by any means
      appropriate.</t>

      <t>A network device should be seen as a means to deploy a service and
      not just as a component of such service. Thus, service delivery
      procedures should not assume the configuration of devices one after the
      other, but rather globally, i.e., at the scale of the network that
      supports the said service. Such a service-driven configuration
      management scheme is therefore meant to facilitate and improve the
      completion of configuration tasks, by means of highly automated,
      service-wise, global configuration procedures.</t>

      <t>This in particular assumes the need for robust configuration
      mechanisms that include appropriate protocol machinery (e.g., from a
      reliable transport mode perspective) to convey configuration information
      between manager and managed entities, as well as reliable consistency
      check procedures. The latter is not only meant to assess the validity of
      all the configuration operations service-wise, but also the efficiency
      of the corresponding yet dynamic policy enforcement and resource
      allocation schemes.</t>

      <t>An implementation example is the case of service providers who could
      dedicate (logical) centralized entities which are responsible for the
      provisioning and the management of participating devices. The main
      function of these centralized entities is to make appropriate decisions
      and generate the decision-derived configuration data that will be
      forwarded to the participating devices. In addition, these centralized
      entities will make sure of the consistency of the decisions that have
      been made to deliver the service, according to a dynamic configuration
      policy enforcement scheme. These logical entities will be responsible
      for assessing whether the enforced policies are compliant with the
      expected behavior and how efficiently they are enforced.</t>

      <t>Service-driven configuration management leads to the following
      assumptions:<list style="symbols">
          <t>Data and information models must be service-oriented,</t>

          <t>Configuration protocol(s) should reuse existing standard data and
          information models as much as possible,</t>

          <t>Configuration protocol(s) should be flexible enough to facilitate
          the support of new features without compromising the protocol
          robustness (especially from a performance and scalability
          standpoints),</t>

          <t>Configuration protocol(s) should provide means to check the
          consistency of configuration information service-wise.</t>
        </list></t>
    </section>

    <section anchor="reqs" title="Detailed Requirements">
      <t></t>

      <section title="Protocol Requirements">
        <t>Configuration information must be provided to the participating
        devices by means of a protocol to be used between such devices and a
        presumably centralized manager entity. The latter can be seen as a
        decision point where configuration information is stored, maintained
        and updated whenever required.</t>

        <t>Decisions about configuring additional features or devices,
        enforcing policies and allocating resources are made accordingly,
        e.g., as a function of the number of Service Level Specification
        templates that are processed per unit of time combined with traffic
        forecasts that are updated on a regular basis. Such decisions are
        converted into configuration information that is forwarded towards the
        relevant managed entities.</t>

        <section title="Functional Requirements">
          <t>The vendor-independent communication protocol for conveying
          configuration information should have the following
          characteristics:<list style="numbers">
              <t>The protocol must be reliable, and be independent from the
              network layer (i.e., configuration information must be conveyed
              over IPv4 and IPv6 network infrastructures indifferently),</t>

              <t>The protocol architecture should provide a means for
              dynamically providing the configuration information to the
              participating devices, so that a high level of automation is
              introduced in the actual delivery of any given service.</t>

              <t>The protocol should provide the relevant means (encoding
              capabilities, operation and command primitives, extension
              capabilities that allow additional operations, etc.) to be able
              to reliably and securely convey configuration information,</t>

              <t>The protocol should be a privileged vector for the dynamic
              provisioning of configuration data, as well as the dynamic
              enforcement of any policy such as a routing policy, a QoS policy
              or a security policy. This requirement suggests the definition
              and the support of vendor-independent instantiation procedures
              that will aim at uniquely identifying the configuration data
              model and the policy enforcement scheme that refer to a given IP
              service.</t>

              <t>The protocol should support a reporting mechanism for various
              purposes, including the assessment of the efficiency of a given
              policy, the ability to dynamically notify the aforementioned
              decision point about the completion of a set of configuration
              tasks, or the ability to dynamically report any event that may
              affect global service operation,</t>

              <t>The protocol should support the appropriate security
              mechanisms to provide guarantees as far as the preservation of
              the confidentiality of the configuration information is
              concerned.</t>

              <t>The protocol should provide a mean of preserving the order in
              which the configuration information should be applied in the
              participating devices. The ordering of the configuration
              information could be implemented by means of sequence numbers,
              timing or scheduling indicators, etc. Through this requirement,
              any aged or disordered configuration information is prevented to
              be applied to the devices.</t>
            </list></t>
        </section>

        <section anchor="perf" title="Performance Requirements">
          <t>The protocol for conveying configuration information within a
          network should be designed so that:<list style="numbers">
              <t>The activation of the protocol by the participating devices
              must not affect the overall performance of such devices,
              whatever the amount of configuration data these devices will
              have to process at any given time.</t>

              <t>The activation of the protocol should not dramatically affect
              the global resources of the network infrastructure that will
              convey configuration information whatever its amount and scope
              (e.g., the set of policies that need to be dynamically
              enforced).</t>
            </list></t>
        </section>

        <section title="Backward Compatibility">
          <t>The introduction and the activation of a protocol for conveying
          configuration information should allow for smooth migration
          procedures, so that vendor-specific and vendor-independent
          configuration procedures may gracefully co-exist on a (hopefully)
          limited period of time.</t>

          <t>Also, in case of any kind of protocol failure, it must be
          possible to rely upon any vendor-specific configuration procedure as
          some kind of rollback procedure. Such a rollback procedure must
          protect services that are up and running from any risk of
          disruption.</t>
        </section>
      </section>

      <section title="Requirements for Configuration Information">
        <t>Configuration tasks are currently performed with vendor-specific
        solutions that reflect technology-specific information. It is
        therefore more and more difficult for a service provider to get a
        unified, homogeneous view of the network resources service-wise
        (rather than device-wise).</t>

        <t>Configuration information should therefore be provided to the
        participating devices as unified, vendor-agnostic, service
        configuration parameters. These parameters must reflect a standardized
        service data model rather than a vendor-specific information model,
        unlike the current situation. Examples of such service data models
        include a tunneling service, an intra-domain routing service, or a VPN
        service.</t>

        <t>The need for a unified, homogeneous access to a multi-vendor
        environment is becoming critical for N-Play, residential and
        corporate, fixed and mobile service providers so that a high level of
        automation can be introduced while proceeding with the configuration
        of the said multi-vendor environment. This unification is clearly
        conditioned by the availability of two key components: A configuration
        protocol (the container) and a set of data models (the content).</t>

        <t>The standardization of these two components has several yet major
        benefits:<list style="symbols">
            <t>Devices are seen as functional blocks that support a set of
            standardized capabilities;</t>

            <t>These functional blocks are described as vendor-independent
            capabilities;</t>

            <t>These functional blocks are all managed homogeneously, whatever
            the underlying technology.</t>
          </list>As a consequence, it becomes possible to add semantic rules
        to automate detection and correction of erroneous configurations,
        either at the scale of a single device or at the scale of a whole
        network. Furthermore, an equipment from vendor X could de replaced by
        another technology from vendor Y with very little impact (if no impact
        at all) on the configuration management procedures.</t>

        <t>To do so, the data models should satisfy the following
        requirements.</t>

        <section title="Network Services">
          <t></t>

          <section title="Interface Identification">
            <t>Configuration information for identification purposes mostly
            deals with the naming of any interface supported by a given
            device. This naming scheme describes the properties of an
            interface, and must take into account all the parameters that are
            required to correctly configure an interface. The following
            information must be provided: <list style="symbols">
                <t>A name, with a generic syntax that is vendor-agnostic by
                nature. The name can define the media type of the interface.
                Depending on the medium type, further information MAY be added
                (such as MTU, bandwidth, supported framing and encapsulation
                modes, etc.).</t>

                <t>The interface technology (e.g., optical / electrical) and
                nominal capacity (e.g., 10 GE / 100 GE).</t>

                <t>Optionally, a logical descriptor (e.g., VLANs declared on
                Ethernet interfaces). In this case the encapsulation mode must
                be part of the configuration information.</t>

                <t>Optionally, a description field that provides general
                (possibly administrative) information about the interface.</t>
              </list></t>
          </section>

          <section title="Quality of Service (QoS)">
            <t>IP services are provided with a level of quality that MAY be
            guaranteed (either qualitatively or quantitatively) by any means
            appropriate. QoS policies should be dynamically enforced according
            to a data model that will accurately reflect all the elementary
            QoS capabilities that MAY be configured and activated to enforce
            such policies.</t>

            <t>For instance, in the case of the activation of the Diffserv QoS
            model within a network infrastructure, the participating routers
            should be provided with the appropriate PHB (Per Hop Behavior)
            configuration parameters.</t>

            <t>Additional information relevant to the service, such as path
            protection, can be provided to the participating devices to
            mitigate network failures. This information can be proactively or
            reactively provided, according to the service level agreed.</t>
          </section>

          <section title="Applications">
            <t>Network devices usually support functions that allow the
            activation of specific services like HTTP, BOOTP, DHCP, SYSLOG,
            etc. These devices must therefore be provided with the
            corresponding configuration information.</t>
          </section>
        </section>

        <section anchor="forwarding" title="Forwarding Services">
          <t></t>

          <section title="Routing and Forwarding Configuration Information">
            <t>Routing and forwarding configuration information deals with the
            decision that should be applied by a participating device to
            forward an incoming IP datagram, according to the (possibly
            service-specific) forwarding and routing policies defined by the
            service provider. From this perspective, the participating devices
            should be provided with the following configuration
            information:<list style="numbers">
                <t>Metric information for IGP route computation purposes,</t>

                <t>Attribute information for BGP route computation
                purposes,</t>

                <t>Static routes (if any).</t>
              </list></t>

            <t>Any candidate protocol must be compliant with the following
            requirements:<list style="numbers">
                <t>Ability to retrieve routing and forwarding tables.</t>

                <t>Ability to retrieve the configuration information of each
                routing/forwarding device.</t>

                <t>Ability to retrieve the capabilities of each
                routing/forwarding device.</t>

                <t>Ability to dynamically enforce policies on active routing
                processes.</t>

                <t>Ability to dynamically inject new routing and forwarding
                entries.</t>

                <t>Ability to receive notifications when route changes
                occurred, tagged by the decision point.</t>
              </list></t>
          </section>

          <section title="Traffic Engineering Configuration Information">
            <t>Traffic Engineering (TE) is an important and often complex task
            of configuration management: the participating devices should be
            provided with the configuration information that will help them to
            select the appropriate routes that lead to a set of destinations,
            according to specific constraints and requirements that may have
            been dynamically negotiated with the customer.</t>

            <t>These constraints may be expressed in terms of time duration
            (e.g., the use of a traffic-engineered route on a weekly basis),
            traffic characterization (e.g., all IP multicast traffic should be
            forwarded along a specific distribution tree), security concerns
            (e.g., use IPsec tunnels), and/or QoS considerations (e.g., EF
            (Expedited Forwarding)-marked traffic <xref
            target="RFC3246"></xref> should always use a subset of
            "EF-compliant" routes).</t>
          </section>

          <section title="Configuration Information for Tunnel Design and Activation">
            <t></t>

            <section title="Tunnel Identification Information">
              <t>The identification of a tunnel should be globally unique,
              especially if the tunnel is to be established and activated
              across autonomous systems. The tunnel identification schemes
              (e.g., endpoint numbering) should be left to service providers,
              assuming that the corresponding formalism is commonly
              understood, whatever the number of autonomous systems the tunnel
              may cross.</t>

              <t>The tunnel identification information should at least be
              composed of the tunnel endpoint identification information. The
              tunnel identification information MAY also be composed of an
              informal description of the tunnel, e.g., the purpose of its
              establishment, customer traffic that may be forwarded into this
              tunnel, etc.</t>
            </section>

            <section title="Tunneling Protocol Configuration Information">
              <t>Any participating device must be provided with the
              configuration information related to the tunneling technique to
              be used for the establishment and the activation of the tunnel.
              Such techniques include Generic Routing Encapsulation (GRE,
              <xref target="RFC2784"></xref>), IP Secure in tunnel mode
              (IPsec, <xref target="RFC2401"></xref>), Layer 2 Tunneling
              Protocol (L2TP, <xref target="RFC2661"></xref>), etc.</t>
            </section>
          </section>
        </section>
      </section>

      <section title="Global Management Requirements ">
        <t></t>

        <section title="Fault Management">
          <t>Mechanisms to monitor and report any fault that affects service
          operation should be independent of the configuration protocol.</t>
        </section>

        <section title="Configuration Management">
          <t>Errors during a configuration procedure could impact the
          availability of a given service offering, while consistency checks
          are mandatory so as to correctly enforce a configuration policy.</t>

          <t>The following requirements have been identified:<list
              style="symbols">
              <t>Provisioning of configuration information should be as
              automated as possible,</t>

              <t>Mechanisms to detect and diagnose configuration errors must
              be supported,</t>

              <t>Consistency of configuration operations service-wise must be
              checked,</t>

              <t>Simulation tools should be used to assess the validity of
              configuration information before it is downloaded to the
              relevant participant devices.</t>

              <t>Autonomic provisioning capabilities should be enabled to
              facilitate new device deployments in an automatic way, ideally
              without any human configuration intervention. Of course, the
              procedure must be designed to allow for administrative
              validation under some events. The purpose of allowing for such
              events is to ease troubleshooting and react to failures events
              when unexpected behaviors are experienced.</t>

              <t>Means to prevent against "mad robot" phenomena should be
              supported.</t>
            </list></t>
        </section>

        <section title="Performance Management">
          <t>Performance management is key for guaranteeing Service Assurance
          by proactively detecting network degradation.</t>

          <t>In a vendor-agnostic scenario, the mechanisms for performance
          management should implement standardized measurements among the
          involved devices, represented by abstract, standard data models.
          There are a number of measurements that can be taken into account
          for different purposes, such as CPP validation, bandwidth
          utilization or network and service level resilience. To that end,
          the performance management tools should provide reporting
          capabilities of the obtained measurements through counters or any
          other mean agnostic to specific vendor implementations.</t>

          <t>The activation (and de-activation) of the reporting capabilities
          MAY be enabled by using automated configuration mechanisms.</t>
        </section>
      </section>

      <section anchor="secmgt" title="Security Management">
        <t></t>

        <section title="Device Authentication">
          <t>It must be possible to activate mutual authentication between
          manager and managed entities. The authentication must be checked
          before exchanging any configuration data, so as to prevent DoS
          (Denial of Service) attacks.</t>
        </section>

        <section title="Integrity of Configuration Information">
          <t>Two types of integrity must be provided. The first one may be
          done at the network layer, e.g., by using the IPsec protocol suite.
          The second type should protect configuration data at the application
          layer (e.g., the entire file configuration is integrity
          protected).</t>
        </section>

        <section title="Confidentiality of Exchanged Data">
          <t>The participating device should provide security functions that
          provide confidentiality. Encryption algorithms must be standard and
          manually or automatically activated.</t>
        </section>

        <section title="Key Management">
          <t>The configuration system must provide a scalable key management
          scheme. The number of keys to be managed must be at most linearly
          proportional to the number of the devices.</t>
        </section>

        <section title="Connection Log">
          <t>The participating device must log all configuration connections.
          At least the following information must be provided:<list
              style="symbols">
              <t>Identity of the device which provided the configuration
              information,</t>

              <t>Date of the connection,</t>

              <t>Identity of the user who has initiated the configuration
              process,</t>

              <t>Description of the configuration information that has been
              forwarded.</t>
            </list></t>
        </section>

        <section title="Profiles">
          <t>The configuration system must allow the definition and the
          activation of several privilege levels. Each level could be
          associated to a set of administrative functions. Each configuration
          administrator could be assigned a specific access level to perform a
          (possibly limited) set of configuration tasks.</t>
        </section>
      </section>
    </section>

    <section anchor="IANA" title="IANA Considerations">
      <t>This document does not require any action from IANA.</t>
    </section>

    <section anchor="Security" title="Security Considerations">
      <t>This document reflects a set of requirements as far as the design and
      the enforcement of configuration policies are concerned for (automated)
      service subscription, delivery and maintenance. The document addresses
      some security concerns that have been depicted in <xref
      target="secmgt"></xref>, and that should be taken into account when
      considering the specification of a protocol that will convey
      configuration information, as well as configuration information
      itself.</t>
    </section>

    <section anchor="Acknowledgements" title="Acknowledgements">
      <t>Many thanks to M. Achemlal and Y. Adam who contributed to a first
      version of this text.</t>

      <t>Thanks for W. George for the comments.</t>
    </section>
  </middle>

  <back>
    <references title="Informative References">
      <?rfc include='reference.RFC.3410'?>

      <?rfc include='reference.RFC.2748'?>

      <?rfc include='reference.RFC.3159'?>

      <?rfc include='reference.RFC.3084'?>

      <?rfc include='reference.RFC.2578'?>

      <?rfc include='reference.RFC.2661'?>

      <?rfc include='reference.RFC.2784'?>

      <?rfc include='reference.RFC.2401'?>

      <?rfc include='reference.RFC.3246'?>

      <?rfc include='reference.RFC.6022'?>

      <?rfc include='reference.RFC.6241'?>

      <?rfc include='reference.RFC.7297'?>

      <?rfc include='reference.RFC.7149'?>

      <?rfc include='reference.RFC.3444'?>

      <?rfc include='reference.I-D.boucadair-connectivity-provisioning-protocol'?>
    </references>
  </back>
</rfc>
