One document matched: draft-jiang-nmrg-an-gap-analysis-00.xml

<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
     which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
     There has to be one entity for each item to be referenced. 
     An alternate method (rfc include) is described in the references. -->
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs), 
     please see http://xml.resource.org/authoring/README.html. -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="3"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space 
     (using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="info" docName="draft-jiang-nmrg-an-gap-analysis-00"
     ipr="trust200902">
  <front>
    <title abbrev="Autonomic Networking Gap Analysis">Gap Analysis for
    Autonomic Networking</title>

    <author fullname="Michael H. Behringer" initials="M.H."
            surname="Behringer">
      <organization>Cisco Systems</organization>

      <address>
        <email>mbehring@cisco.com</email>
      </address>
    </author>

    <author fullname="Brian Carpenter" initials="B. E." surname="Carpenter">
      <organization abbrev="Univ. of Auckland"></organization>

      <address>
        <postal>
          <street>Department of Computer Science</street>

          <street>University of Auckland</street>

          <street>PB 92019</street>

          <city>Auckland</city>

          <code>1142</code>

          <country>New Zealand</country>
        </postal>

        <email>brian.e.carpenter@gmail.com</email>
      </address>
    </author>

    <author fullname="Sheng Jiang" initials="S." surname="Jiang">
      <organization>Huawei Technologies Co., Ltd</organization>

      <address>
        <postal>
          <street>Q14, Huawei Campus, No.156 Beiqing Road</street>

          <city>Hai-Dian District, Beijing, 100095</city>

          <country>P.R. China</country>
        </postal>

        <email>jiangsheng@huawei.com</email>
      </address>
    </author>

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

    <area>Internet Research Task Force</area>

    <workgroup>Network Management Research Group</workgroup>

    <keyword>Autonomic Network, Gap Analysis</keyword>

    <abstract>
      <t>This document summarises a problem statement for an IP-based
      autonomic network that is mainly based on distributed network devices.
      The document reviews the history and current status of autonomic aspects
      of IP networks. It then reviews the current network management style,
      which is still heavily depending on human administrators. Finally the
      document describes the general gaps between the ideal autonomic network
      concept and the current network abilities.</t>
    </abstract>
  </front>

  <middle>
    <section anchor="intro" title="Introduction">
      <t>The general goals and relevant definitions for autonomic networking
      are discussed in <xref
      target="I-D.irtf-nmrg-autonomic-network-definitions"></xref>. In
      summary, the fundamental goal of an autonomic network is
      self-management, including self-configuration, self-optimization,
      self-healing and self-protection. Whereas interior gateway routing
      protocols such as OSPF and IS-IS largely exhibit these properties, most
      other aspects of networking require top-down configuration often
      involving human administrators and a considerable degree of
      centralisation. In essence Autonomous Networking is putting all network
      configuration onto the same footing as routing, limiting manual or
      database-driven configuration to an essential minimum. It should be
      noted that this is highly unlikely to eliminate the need for human
      administrators, because many of their essential tasks will remain. The
      idea is to eliminate tedious and error-prone tasks, for example manual
      calculations, cross-checking between two different configuration files,
      or tedious data entry. Higher level operational tasks, and
      trouble-shooting, will remain to be done in any case.</t>

      <t>Note in draft: This is a preliminary version. It certainly lacks
      information about current status, and it lacks many external references.
      Especially the final section (<xref target="Gaps"></xref>) is very
      preliminary. Comments and suggestions are very welcome.</t>
    </section>

    <!-- intro -->

    <section anchor="terms" title="Terminology">
      <t>The terminology defined in <xref
      target="I-D.irtf-nmrg-autonomic-network-definitions"></xref> is used in
      this document. Additional terms include:</t>

      <t><list style="symbols">
          <t>Automatic: A process that occurs without human intervention, with
          step-by-step execution of rules. However it relies on humans
          defining the sequence of rules, so is not Autonomic in the full
          sense. For example, a start-up script is automatic but not
          autonomic.</t>
        </list></t>
    </section>

    <!-- terms -->

    <section anchor="Status"
             title="Current Status of Autonomic Aspects of IP Networks">
      <t>This section discusses the history and current status of autonomy in
      various aspects of network configuration, in order to establish a
      baseline for the gap analysis. In one particular area, routing
      protocols, autonomic information exchange and decision is a well
      established mechanism. The question is how to extend autonomy to cover
      all kinds of network management objectives.</t>

      <section title="IP Address Management and DNS">
        <t>Originally there was no alternative to completely manual and static
        management of IP addresses. Once a site had received an IPv4 address
        assignment (usually a Class C /24 or Class B /16, and rarely a Class A
        /8) it was a matter of paper-and-pencil design of the subnet plan (if
        relevant) and the addressing plan itself. Subnet prefixes were
        manually configured into routers, and /32 addresses were assigned
        administratively to individual host computers, and configured manually
        by system administrators. Records were typically kept in a plain text
        file or a simple spreadsheet.</t>

        <t>Clearly this method was clumsy and error-prone as soon as a site
        had more than a few tens of hosts, but it had to be used until DHCP
        <xref target="RFC2131"></xref> became a viable solution during the
        second half of the 1990s. DHCP made it possible to avoid manual
        configuration of individual hosts (except, in many deployments, for a
        small number of servers configured with static addresses).</t>

        <t>In terms of management, it is difficult to separate IP address
        management from DNS management. At roughly the same time as DHCP came
        into widespread use, it became very laborious to manually maintain DNS
        source files in step with IP address assignments. Because of reverse
        DNS lookup, it also became necessary to synthesise DNS names even for
        hosts that only played the role of clients. Therefore, it became
        necessary to synchronise DHCP server tables with forward and reverse
        DNS. For this reason, Internet Protocol address management tools
        emerged. These are, however, a centralised and far from autonomic type
        of solution.</t>

        <!-- <t>IPv6 has complicated the situation. Using DHCPv6 <xref
        target="RFC3315"></xref>, the situation is similar to IPv4. However,
        IPv6 also allows stateless address auto-configuration, which is
        largely autonomic, as long as the local router is correctly configured
        to provide Router Advertisements. There is significant disagreement in
        the community which of these methods is better, and there are
        coexistence issues.</t> -->

        <t>A related issue is prefix delegation, especially in IPv6 when more
        than one prefix may be delegated to the same physical subnet. DHCPv6
        Prefix Delegation <xref target="RFC3633"></xref> is a useful solution,
        but how this topic is to be handled in home networks is still an open
        question. Still further away is automated assignment and delegation of
        IPv4 subnet prefixes.</t>

        <t>Another complication is the possibility of Dynamic DNS Update <xref
        target="RFC2136"></xref>. With appropriate security, this is an
        autonomic approach, where no human intervention is required to create
        the DNS records for a host. Also, there are coexistence issues with a
        traditional DNS setup.</t>
      </section>

      <section title="Routing">
        <t>Since a very early stage, it has been a goal that Internet routing
        should be self-healing when there is a failure of some kind in the
        routing system (i.e. a link or a router goes wrong). Also, the problem
        of finding optimal routes through a network was identified many years
        ago as a problem in mathematical graph theory, for which well known
        algorithms were discovered (the Dijkstra and Bellman-Ford algorithms).
        Thus routing protocols became largely autonomic in the 1980s, as soon
        as the network was big enough for manual configuration of routing
        tables to become difficult.</t>

        <t>IGP routers do need some initial configuration data to start up the
        autonomic routing protocol. Also, BGP-4 routers need static
        configuration of routing policy data. So far, this policy
        configuration has not been made autonomic at all.</t>
      </section>

      <section title="Configuration of Default Router">
        <t>Originally this was a manual operation. Since the deployment of
        DHCP, this has been automatic as far as most IPv4 end systems are
        concerned, but the DHCP server must be appropriately configured. In
        simple environments such as a home network, the DHCP server resides in
        the same box as the default router, so this configuration is also
        automatic. In more complex environments, where an independent DHCP
        server or a local DHCP relay is used, configuration is more complex
        and not automatic.</t>

        <t>In IPv6 networks, the default router is provided by Router
        Advertisement messages <xref target="RFC4861"></xref> from the router
        itself, and all IPv6 hosts make use of it. The router may also provide
        more complex Route Information Options. The process is automatic as
        far as all IPv6 end systems are concerned, and DHCPv6 is not involved.
        Howwever there are still open issues when more than one prefix is in
        use on a subnet and more than one first-hop router may be available as
        a result.</t>
      </section>

      <section title="Hostname Lookup">
        <t>Originally host names were looked up in a static table, often
        referred to as /etc/hosts from its traditional file path in Unix
        systems. When the DNS was deployed during the 1980s, all hosts needed
        DNS resolver code, and needed to be configured with the IP addresses
        (not the names) of suitable DNS servers. Like the default router,
        these were originally manually configured. Today, they are provided
        automatically via DHCP or DHCPv6 <xref target="RFC3315"></xref>. For
        IPv6 end systems, there is also a way for them to be provided
        automatically via a Router Advertisement option. However, the DHCP or
        DHCPv6 server, or the IPv6 router, need to be configured with the
        appropriate DNS server addresses.</t>
      </section>

      <section title="User Authentication and Accounting">
        <t>Originally, user authentication and accounting are mainly based on
        the physical connectivities. Network operators charged based on the
        set up of dedicated physical links with users. Autonomic user
        authentication are introduced by Point-to-Point Protocol <xref
        target="RFC1661"></xref>, <xref target="RFC1994"></xref> and RADIUS
        protocol <xref target="RFC2865"></xref>, <xref
        target="RFC2866"></xref> in early 1990s. As long as a user complete
        online authentication through RADIUS protocol, the accounting for that
        user starts on AAA server autonomically. This mechanism enables
        charging business model based on the usage of users, either traffic
        based or time based. However, the management for user authentication
        information remains manual by network administrators.</t>
      </section>

      <section title="Security">
        <t>Security has many aspects that need configuration and are therefore
        candidates to become autonomic. On the other hand, it is essential
        that a network's central policy should be applied strictly for all
        security configuration. As a result security has largely been based on
        centrally imposed configurations.</t>

        <t>Many aspects of security depend on policy, for example firewall
        policies. Policies are by definition human made and will therefore
        also persist in an autonomic environment. However, policies are
        becoming more high-level, abstracting for example addressing, and
        focusing on the user or application. The methods to manage, distribute
        and apply policy, and to monitor compliance and violations could be
        autonomic.</t>

        <t>Today, many security mechanisms show some autonomic properties. For
        example user authentication via 802.1x allows automatic mapping of
        users after authentication into logical contexts (typically VLANs).
        While today configuration is still very important, the overall
        mechanism displays signs of self-adaption to changing situations.</t>

        <t>BGP Flowspec <xref target="RFC5575"></xref> allows a partially
        autonomic threat defense mechanism, where threats are identified, the
        flow information is automatically distributed, and counter-actions can
        be applied. Today typically a human operator is still in the loop to
        check correctness, but over time such mechanisms can become more
        autonomic.</t>

        <t>Negotiation capabilities, present in many security protocols, also
        display simple autonomic behaviours. In this case a security policy
        about algorithm strength can be configured into servers but will
        propagate automatically to clients. A proposal has been made recently
        for automatic bootstrapping of trust in a network <xref
        target="I-D.behringer-default-secure"></xref>. Solutions for
        opportunistic encryption have been defined <xref
        target="RFC4322"></xref>, <xref
        target="I-D.farrelll-mpls-opportunistic-encrypt"></xref>, but these do
        not adhere to a central policy.</t>
      </section>

      <section title="Miscellaneous">
        <t>There are innumerable other properties of network devices and end
        systems that today need to be configured either manually or using a
        management protocol such as SNMP <xref target="RFC1157"></xref> or
        NETCONF <xref target="RFC6241"></xref>. In a truly autonomic network,
        all of these would need to either have satisfactory default values or
        be configured automatically. Some examples are parameters for tunnels
        of various kinds, flows (in an SDN context), quality of service,
        service function chaining, energy management, system identification,
        NTP configuration etc. Even one undefined parameter would be
        sufficient to prevent fully autonomic operation.</t>
      </section>
    </section>

    <!-- history -->

    <!--
      <section anchor="summary" title="Summary of Autonomic Status and Trends">
      <t>The most advanced area is of course routing protocols, where we
      observe that a minimal amount of information must be pre-configured
      (neighbour routers, prefixes supported, and BGP-4 policies) and the rest
      is calculated dynamically as a result of peer-to-peer communication with
      other routers. In all other areas, there has been a slow progress over
      many years from fully manual configuration towards top-down
      configuration from central administrators or network management systems
      driven by databases. There are only a few instances, such as negotiation
      of cryptographic algorithms, where automation is not in the top-down
      style that relies ultimately on humans - either to correctly create and
      maintain configuration files, or to correctly use a network management
      system to do this work. At the moment the trend seems to be towards more
      widespread deployment of tools to help centralised configuration, such
      as IPAM tools, rather than to move away from this towards a more
      distributed and autonomic approach.</t>
    </section> -->

    <!-- summary-->

    <section anchor="HumanDependencies"
             title="Current Non-Autonomic Behaviors">
      <t>In the current networks, many operations are still heavily depending
      on human intelligence and decision, or on centralised top-down network
      management systems. These operations are the targets of Autonomic
      Network technologies. The ultimate goal of Autonomic Network is to
      replace tedious human operations by autonomic functions, so that the
      networks can independently run without having to ask human support for
      routine details, while it remains possible to restore human intervention
      when unavoidable. Of course, there would still be the absolute minimum
      of human input required, particularly during the network establishment
      stage, and during difficult trouble-shooting.</t>

      <t>This section analyzes the existing human and central dependencies in
      the current networks.</t>

      <section title="Network Establishment">
        <t>Network establishment requires network operators to analyze the
        requirements of the new network, design a network archetecture and
        topology, decide device locations and capacities, set up hardware,
        design network services, choose and enable required protocols,
        configure each device and each protocol, set up user authentication
        and accounting policies and databases, design and deploy security
        mechanisms, etc.</t>

        <t>Overall, these jobs are quite complex work that cannot become fully
        autonomic in the forseeable future. However, part of these jobs may be
        able to become autonomic, such as device and protocol configurations
        and database population. The initial network management
        policies/behaviors may also be transplanted from other networks and
        automatically localized.</t>
      </section>

      <section title="Network Maintenance & Management">
        <t>The network maintenance and management are very different for ISP
        networks and enterprise networks. ISP networks have to change much
        more frequently than enterprise networks, given the fact that ISP
        networks have to serve a large number of customers who have very
        diversified requirements. The current rigid model is that network
        administrators design a limited number of services for customers to
        order. New requirements of network services may not be able to be met
        quickly by human management. Given a real-time request, the response
        must be autonomic, in order to be flexible and quickly deployed.
        However, behind the interface, describing abstracted network
        information and user authorization management may have to depend on
        human intelligence from network administrators in the forseeable
        future. User identification integration/consolidation among networks
        or network services are another challenge for autonomic network
        access. Currently, the end users have to manually manage their user
        accounts and authentication information when they switch among
        networks or network services.</t>

        <t>Classical network maintenance and management mainly manages the
        configuration of network devices. Tools have developed to enable
        remote management and make the management easier. However, the
        decision of each configuration depends either on human intelligence or
        rigid templates. This is the source of most network configuration
        errors. It is also the barrier to increase the utility of network
        resources because the human management cannot respond quickly enough
        to network events, such as traffic bursts, etc. For example,
        currently, a light load is normally assumed in network design because
        there is no mechanism to properly handle a sudden traffic flood. It is
        actually normal to avoid network crashes caused by traffic overload by
        wasting a huge amount of resources.</t>

        <t>Autonomic decision processes of configuration would enable dynamic
        management of network resources (by managing resource relevant
        configuration). Self-adapting network configuration would adjust the
        network into the best possible situation, which also prevents
        configuration errors from having lasting impact.</t>
      </section>

      <section title="Troubleshooting and Recovery">
        <t>The current networks are suffering difficulties in locating the
        cause of network failures. Although the network devices may issue many
        warnings during running, most of them are not sufficiently precise to
        be identified as errors. Some of them are early warnings that would
        not develop into real errors. Others are in effect random noise. For
        many scenarios, human experience is vital to identify real issues and
        locate them. This situation may be improved by associating warnings
        from multiple network devices together. Also, introducing automated
        learning techniques (comparing current warnings with historical
        relationships between warnings and actual faults) could increase the
        possibility and success rate of autonomic network diagnoses and
        troubleshooting.</t>

        <t>Depending on the network errors, some of them may require human
        interventions, particularly for hardware failures. Meanwhile, some
        network management behavior may help to reduce the impact from errors,
        such as switching traffic flows around. Today this is usually manual.
        Software failures and configuration errors (including to roll back
        software versions and to reboot hardware) currently depend on humans.
        Such problems could be autonomically corrected if there were
        diagnostics and recovery functions defined in advance for them. This
        would fulfill the concept of self-healing.</t>
      </section>
    </section>

    <section anchor="Gaps" title="Approach toward Autonomy">
      <t>The task of autonomic networking is to build up individual autonomic
      decision processes that could properly combine to respond to every type
      of network event. This section (when complete) will outline what needs
      to be developed.</t>

      <section title="More Coordination among Devices or Network Partitions">
        <t>Events in networks are normally not independent. They are
        associated with each other. But most of current response functions are
        based on independent processes. The network events that may naturally
        happen distributed should be associated in the autonomic
        processes.</t>

        <t>In order to make right or good decisions autonomically, the network
        devices need to know more information than just reachability (routing)
        information from the relevant or neighbor devices. There are
        dependencies between such information and configurations. Currently,
        most of these configurations currently require manual coordination by
        network administrators.</t>

        <t>There are therefore increased requirements for horizontal
        information exchanging in the networks. Particularly, negotiation
        among network devices are needed for autonomic decision. <xref
        target="I-D.jiang-config-negotiation-ps"></xref> analyzes such
        requirements. Although there are many existing protocols with
        negotiation ability, each of them are only serve a specifc and narrow
        purpose. <xref target="I-D.jiang-config-negotiation-protocol"></xref>
        is one of the attempts to create a generic negotiation platform, which
        would support different negotiation objectives.</t>
      </section>

      <section title="Benefit from Knowledge">
        <t>The more knowledge we have, the more intelligent we are. It is the
        same for networks and network management. It is when one component in
        the network lacks knowledge that affects what it should do, and
        another component has that knowledge, that we usually rely on a human
        operator or a centralised management tool to convey the knowledge.</t>

        <!-- The deep reason why human
        decision have to be needed relies on either lacking of information or
        experience. Note from Sheng: this statement is useful, I think. But it
        seems not fit the context here. I also cannot find a better place for
        it. -->

        <t>Up to now, most available network knowledge is only the current
        network status, either inside a device or relevant data from other
        devices.</t>

        <t>However, historic knowledge is very helpful to make correct
        decisions, in particular to reducing network oscillation or to manage
        network resources over time. Transplantable knowledge from other
        networks can be helpful to initially set up a new network or new
        network devices. Knowledge of relationship between network events and
        network configuration may help network to decide the best parameters
        according to real performance feedback.</t>
      </section>
    </section>

    <!-- gaps -->

    <section anchor="security" title="Security Considerations">
      <t>This document is focussed on what is missing to allow autonomic
      network configuration, including of course security settings. Therefore,
      it does not itself create any new security issues. It is worth
      underlining that autonomic technology must be designed with strong
      security properties from the start, since a network with vulnerable
      autonomic functions would be at great risk.</t>
    </section>

    <section anchor="IANA" title="IANA Considerations">
      <t>This memo includes no request to IANA.</t>
    </section>

    <section anchor="ack" title="Acknowledgements">
      <t><!--The authors would like to acknowledge the valuable comments made by ... and others.-->This
      document was produced using the xml2rfc tool <xref
      target="RFC2629"></xref>.</t>
    </section>
  </middle>

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

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

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

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

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

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

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

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

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

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

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

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

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

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

      <?rfc include="reference.I-D.jiang-config-negotiation-ps"?>

      <?rfc include="reference.I-D.jiang-config-negotiation-protocol"?>

      <?rfc include="reference.I-D.irtf-nmrg-autonomic-network-definitions.xml"?>

      <?rfc include="reference.I-D.behringer-default-secure.xml"?>

      <?rfc include="reference.I-D.farrelll-mpls-opportunistic-encrypt.xml"?>
    </references>
  </back>
</rfc>