<?xml version="1.0" encoding="US-ASCII"?>
<!-- This is built from a template for a generic Internet Draft. Suggestions for
     improvement welcome - write to Brian Carpenter, brian.e.carpenter @ gmail.com -->
<!-- This can be converted using the Web service at http://xml.resource.org/experimental.html
     (which supports the latest, sometimes undocumented and under-tested, features.) -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<!-- You want a table of contents -->
<?rfc symrefs="yes"?>
<!-- Use symbolic labels for references -->
<?rfc sortrefs="yes"?>
<!-- This sorts the references -->
<?rfc iprnotified="no" ?>
<!-- Change to "yes" if someone has disclosed IPR for the draft -->
<?rfc compact="yes"?>
<!-- This defines the specific filename and version number of your draft (and inserts the appropriate IETF boilerplate -->
<rfc category="info" docName="draft-du-anima-an-intent-05" ipr="trust200902">
  <front>
    <title abbrev="ANIMA Intent Policy">ANIMA Intent Policy and Format</title>

    <author fullname="Zongpeng Du" initials="Z." surname="Du">
      <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>duzongpeng@huawei.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>

    <author fullname="Jeferson Campos Nobre" initials="J. " surname="Nobre">
      <organization>Federal University of Rio Grande do Sul</organization>

      <address>
        <postal>
          <street/>

          <city>Porto Alegre</city>

          <country>Brazil</country>
        </postal>

        <email>jcnobre@inf.ufrgs.br</email>
      </address>
    </author>

    <author fullname="Laurent Ciavaglia" initials="L." surname="Ciavaglia">
      <organization>Alcatel Lucent</organization>

      <address>
        <postal>
          <street>Route de Villejust</street>

          <city>Nozay 91620</city>

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

        <email>laurent.ciavaglia@alcatel-lucent.com</email>
      </address>
    </author>

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

      <address>
        <postal>
          <street>Building D, 45 Allee des Ormes</street>

          <city>Mougins 06250</city>

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

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

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

    <area>Operations and Management</area>

    <workgroup>ANIMA WG</workgroup>

    <keyword>Autonomic Networking, Intent</keyword>

    <abstract>
      <t>One of the goals of autonomic networking is to simplify the
      management of networks by human operators. Intent Based Networking (IBN)
      is a possible approach to realize this goal. With IBN, the operator
      indicates to the network what to do (i.e. her intent) and not how to do
      it. In the field of Policy Based Management (PBM), the concept of intent
      is called a declarative policy. This document proposes a refinement of
      the intent concept initially defined in <xref target="RFC7575"/> for
      autonomic networks by providing a more complete definition, a
      life-cycle, some use cases and a tentative format of the ANIMA Intent
      Policy.</t>
    </abstract>
  </front>

  <middle>
    <section anchor="intro" title="Introduction">
      <t>One of the goals of autonomic networking is to simplify the
      management of networks by human operators. Intent Based Networking (IBN)
      is a possible approach to realize this goal. With IBN, the operator
      indicates to the network what to do (i.e. her intent) and not how to do
      it. In the field of Policy Based Management (PBM), the concept of intent
      is called a declarative policy. This document proposes a refinement of
      the intent concept initially defined in <xref target="RFC7575"/> for
      autonomic networks by providing a more complete definition, a
      life-cycle, some use cases and a tentative format of the ANIMA Intent
      Policy.</t>

      <t>An Autonomic Network must be able to operate with minimum
      intervention from human operators. However, it still needs to receive
      some form of guidance (e.g. ANIMA Intent Policies) in order to fulfill
      the operator requirements.</t>

      <t>In PBM, the Policy Continuum defines the levels at which the policies
      are defined (policy creation point), consumed (policy execution point)
      and translated (policy interpretation point). Using PBM, the operator
      can manage the network as a whole, and does not need to configure each
      individual devices in the network. The transformation of the
      high-level/abstract policies to the low-level device configurations is
      realized automatically by a set of functions usually regrouped inside a
      Policy Engine.</t>

      <t>The use of policies and in particular of declarative policies assumes
      that the entities in the Autonomic Network receiving the ANIMA Intent
      Policy are capable of processing (refining and/or executing) the policy
      with no ambiguity. For that, the format of the ANIMA Intent Policy and
      the hierarchy of policy levels must be specified.</t>

      <t>This document proposes a base format of the ANIMA Intent Policy.
      Application-specific extensions of the base format should be defined on
      a per need basis in dedicated documents.</t>
    </section>

    <!-- intro -->

    <section title="Requirements Language and Terminology">
      <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
      "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
      "OPTIONAL" in this document are to be interpreted as described in <xref
      target="RFC2119"/> when they appear in ALL CAPS. When these words are
      not in ALL CAPS (such as "should" or "Should"), they have their usual
      English meanings, and are not to be interpreted as <xref
      target="RFC2119"/> key words.</t>

      <t><list style="hanging">
          <t hangText="Autonomic Function:">A feature or function which
          requires no configuration, and can derive all required information
          either through self-knowledge, discovery or through Intent.</t>

          <t hangText="Autonomic Node:">A node which employs exclusively
          Autonomic Functions.</t>

          <t hangText="Legacy Node:">A non-autonomic node, i.e., a node which
          employs some non-autonomic functions.</t>

          <t hangText="Autonomic Network:">A network containing exclusively
          Autonomic Nodes. It may contain one or several Autonomic
          Domains.</t>

          <t hangText="Autonomic Domain:">A collection of autonomic nodes that
          instantiate the same Intent.</t>

          <t hangText="Autonomic Service Agent:">An agent implemented on an
          Autonomic Node which implements an Autonomic Function.</t>

          <t hangText="Intent:">An abstract, high-level policy used to operate
          the network.</t>

          <t hangText="ANIMA Intent Policy:">A declarative type of policy used
          in Autonomic Networks.</t>

          <t hangText="Configlet:">Intent is interpreted on the Autonomic
          Node, and the results will be interpreted and stored in a local
          format on the Autonomic Node. This stored version is known as a
          "configlet".</t>

          <t hangText="NOC:">A network operations center is the location where
          network monitoring and control is exercised.</t>
        </list></t>
    </section>

    <section anchor="intent" title="Concept of ANIMA Intent Policy">
      <t>In the scope of autonomic networking, the definition of intent can be
      found in <xref target="I-D.ietf-anima-reference-model"/>, in which
      intent is described as "an abstract, declarative, high-level policy used
      to operate an autonomic domain, such as an enterprise network."</t>

      <t>An Autonomic Network will comprise multiple ANIMA Intent Policies.
      Different ANIMA Intent Policies will be "interpreted" by different
      entities in autonomic networks, and the "level" of understanding of the
      intent will impact how the intent will be presented to this entity. So
      there should be "intermediate" mechanisms/functions that cater for the
      intent translation continuum across the heterogeneity (in policy
      capabilities) of the network entities. Also, ANIMA Intent Policies will
      possibly overlap and this overlapping should be managed (e.g., avoid
      conflicts, resolve applicable policies in context).</t>
    </section>

    <section anchor="life.cycle" title="Intent Life Cycle">
      <t>This section describes a top-down flow about how an ANIMA Intent
      Policy is derived through an autonomic network.</t>

      <t/>

      <t><list style="numbers">
          <t>Business goals: The network owner wants the network to follow
          some business goals. These goals are initially not formalised in a
          particular way. A Domain Specific Language (DSL) is used to format
          these goals in a form subsequent components can interpret and
          process.</t>

          <t>ANIMA Intent Policy (or Intent): Is the formalisation of business
          goals so that computer can deal with them. It is encoded as a file
          (or several files), and this file must be "given to the
          network".</t>

          <t>Ingestion: The Intent file(s) get instantiated on an autonomic
          node. On a particular node, an intent file is "ingested". After
          that, it needs to be distributed.</t>

          <t>Intent Distribution: Intent is flooded to all nodes in a network.
          Every node has a copy of the original "Intent" file(s), without
          modification. Each node re-distributes the original Intent files,
          without modification. Therefore, Intent is optional and transitive
          in nature. The Intent files must now be interpreted by each node.
          Editor's note: need to better defined meaning of "optional" and
          "transitive".</t>

          <t>Intent splitting (on each node): Intent is split into sections,
          one for the ANI itself, others for specific Autonomic Functions.
          ASAs are notified if there is new Intent for them. Some intent
          sections may not apply to a particular node. Now each component of a
          node (ANI, all ASAs) know their respective Intent.</t>

          <t>Intent Interpretation (on each node, by each function): The ANI
          as well as all ASAs on a node interpret their respective Intent
          section(s). It gets translated into a "target configuration", taking
          into account local state. For this translation, it may be necessary
          for ASAs to communicate with ASAs on other nodes, to pass on
          resources (IP addresses), to negotiate, etc. All such communications
          may be triggered by Intent, but the communications themselves are
          not Intent. (NB: This interpretation could also be done centrally,
          and the resulting configurations distributed; This is of course an
          option, but out the scope of ANIMA.) After interpreting Intent
          locally on each node, each node has target configlet to apply.
          Editor's note: define new terms such as "configlet"</t>

          <t>Conflict Resolution with non-autonomic management (on each node):
          The target configlet resulting from Intent has the lowest priority;
          meanwhile, any other management method (CLI, NETCONF, etc.)
          overrides Intent.</t>

          <t>Conflict Resolution between autonomic components (on each node):
          Each autonomic function needs to register with a "conflict
          resolution function" which parameters it modifies; in case of
          conflict, the conflict resolution function takes a decision and
          feeds that back to the autonomic functions. This may modify the
          target configlet.</t>

          <t>Applying the target configlet.</t>

          <t>Feedback loops to NOC: The NOC needs to know about certain
          conditions, such as conflicts with non-autonomic management. Not all
          conflicts can be resolved automatically, so they may require NOC
          actions. Undesirable states (deviations from expected default
          behaviour) may have to be communicated too. To some extent, Intent
          itself can specify which conditions should trigger feedback loops to
          the NOC. Feedback loops may happen at other phases as well (ex:
          8).</t>
        </list></t>
    </section>

    <section title="Use Cases for ANIMA Intent Policy">
      <t>In this section, some use cases are introduced to clarify the concept
      of ANIMA Intent Policy. It should be noted that intent is defined per
      Autonomic Function, and can also be a general one related to multiple
      AFs.</t>

      <t>The first example is about "arranging VM guest distribution". The
      autonomic network is supposed to be able to monitor the CPU/power
      utilization on each host machine, and control the status of each host
      machine (e.g. turn on/off). The operator may have an intent "there
      should be enough hosts to keep CPU utilization less than 70%", and also
      another one "there are few enough hosts powered so that electricity
      isn't wasted".</t>

      <t>These two intents can both influence the ASA responsible for
      controlling how many hosts are needed. The final decision is made
      according to multiple factors, including network environment and intents
      entered by the operators.</t>

      <t>In this case, the first intent should have a higher priority than the
      later one. The two intents should be analyzed and coordinated to ensure
      the ASA act rightly.</t>

      <t>Another example is about coordination of "load balancing" intent and
      "energy saving" intent. Autonomic Network of Operator A is composed of
      Autonomic Function Agents such as load balancing (LB_AFA) and energy
      saving (ES_AFA). Operator A wants to limit the proportion of links
      loaded over a certain threshold and thus defines an Intent to activate
      load balancing if the load is superior to 0.6 on more than 30% of the
      links.</t>

      <t>Meanwhile, operator A wants different load balancing policies per
      (technology, administrative, topology) domain. Let's consider a
      metropolitan network domain and a core network domain, or different LB
      policy for border routers than interior routers. For the metropolitan
      network domain, Operator A defines an Intent to minimize the link load
      variance. For the core network domain, Operator A applies the previously
      defined intent (activate load balancing if the load is superior to 0.6
      on more than 30% of the links).</t>

      <t>The intents will be distributed to the right network domain, and take
      effect after being interpreted and coordinated, and it is easy to change
      them without the need to configure every device manually.</t>
    </section>

    <section title="Distribution of ANIMA Intent Policy">
      <t>The distribution of intent can be done by using GRASP <xref
      target="I-D.ietf-anima-grasp"/> and ACP <xref
      target="I-D.ietf-anima-autonomic-control-plane"/>. The operator can
      issue a new intent or modify an intent through any authorized nodes in
      the autonomic network. After that, the intent will be flooded to all the
      nodes in the autonomic network. Another scenario is that when a new node
      joins into an autonomic domain, it may receive an intent from its
      neighbor.</t>

      <t>For example, GRASP can be used to communicate version number of the
      intent, and meanwhile, a URL where to find it.</t>

      <t>{Editor Notes: other distribution methods are also possible. }</t>
    </section>

    <section title="Management of ANIMA Intent Policy">
      <t>Every Autonomic Node in the Autonomic domain should own an intent
      with the same version. Any updating of intent will cause the change of
      the intent version number. To ensure all the nodes own the same intent,
      the nodes should be able to communicate with neighbors in the domain
      about the version of the intent. If its neighbor has a newer version of
      intent, it can request an intent update.</t>

      <t>If the operator issues a new intent or modify intents, it will
      trigger a domain level updating of intent. Nodes in the Autonomic
      Network should be aware which domain it belongs to, and accept intent
      for that domain.</t>

      <t>{Editor Notes: talk about the questions as follows. When/on which
      triggers are intents generated, updated? How the domain(s) are defined
      and recognized (if I am an AFA, how do I know I am part of domain x, y
      or z...?). }</t>
    </section>

    <section title="Interpretation of ANIMA Intent Policy">
      <t>After receiving an intent, the Autonomic Node should confirm whether
      it is acceptable, according to the domain name information, intent
      version, signature, and so on. If it passes the validation, an intent
      interpretation module will be involved to decide which ASAs will be
      involved in. Coordination of intents may be needed before the execution
      of the policies interpreted from the intent.</t>

      <t>{Editor Notes: talk about the questions as follows. How the AFAs
      receive, understand and react to an intent? }</t>

      <t>{Editor Notes: how the splitting (step 5 in the Life Cycle section)
      happens here can be explained more here. It would be better that an
      example can be introduced here.}</t>
    </section>

    <section anchor="format.of.Intent"
             title="Uniform Format of the ANIMA Intent Policy">
      <t>{Editor Notes: Format of Intent is FFS. It is suggested to contain
      the following information.}</t>

      <t>This section proposes a uniform intent format. It uses the tag-based
      format.</t>

      <t/>

      <t><list style="hanging">
          <t hangText="Autonomic intent:">The root tag for the Autonomic
          Network Intent.</t>

          <t hangText="Intent type:">It indicates the intent type, which is
          associated with a specific Autonomic Function.</t>

          <t hangText="Autonomic domain:">It indicates the domain of the
          Autonomic Network. It is also the scope of the Autonomic Network
          Intent.</t>

          <t hangText="Intent version:">It indicates the version of the ANIMA
          Intent Policy. This is an important feature for synchronization.</t>

          <t hangText="Model version:">The version of the model used to define
          the intent.</t>

          <t hangText="Name:">The name of the intent which describes the
          intent for human operators.</t>

          <t hangText="Signature:">The signature is used as a security
          mechanism to provide authentication, integrity, and
          non-repudiation.</t>

          <t hangText="Timestamp:">The timestamp of the creation of the intent
          using the format supported by the IETF [TBC].</t>

          <t hangText="Lifetime:">The lifetime in which the intent may be
          observed. A special case of the lifetime is the definition of
          permanent intents.</t>

          <t hangText="Content:">It contains the main information of the
          intent. It may include objects, policies, goals and configuration
          data. The detailed contents and formats should be defined under
          their specific situations by documents that specifies the Autonomic
          Service Agent. Within the content, there may be sub_intents.</t>
        </list></t>

      <t/>
    </section>

    <section anchor="security" title="Security Considerations">
      <t>Relevant security issues are discussed in <xref
      target="I-D.ietf-anima-grasp"/>. The ANIMA Intent Policy requires strong
      security environment from the start, because it would be great risk if
      the ANIMA Intent Policy had been maliciously tampered. The Autonomic
      Intent should employ a signature scheme to provide authentication,
      integrity, and non-repudiation.</t>
    </section>

    <!-- security -->

    <section anchor="iana" title="IANA Considerations">
      <t>This document defines one new format. The IANA is requested to
      establish a new assigned list for it.</t>
    </section>

    <!-- iana -->

    <section anchor="ack" title="Acknowledgements">
      <t>The authors of this draft would like to thank the following persons
      for their valuable feedback and comments: Bing Liu, Brian Carpenter,
      Michael Richardson, Joel Halpern, John Strassner, and Jason Coleman.</t>

      <t>This document was produced using the xml2rfc tool <xref
      target="RFC2629"/>.</t>
    </section>

    <!-- ack -->

    <section anchor="changes" title="Change log [RFC Editor: Please remove]">
      <t>draft-du-anima-an-intent-00: original version, 2015-06-11.</t>

      <t>draft-du-anima-an-intent-01: add intent use case section, add some
      elements for the format section, and coauthor Jeferson Campos Nobre and
      Laurent Ciavaglia, 2015-07-06.</t>

      <t>draft-du-anima-an-intent-02: add the intent concept section, and some
      other sections, 2015-10-14.</t>

      <t>draft-du-anima-an-intent-03: modify the use case section, and add
      some other contents, 2016-03-17.</t>

      <t>draft-du-anima-an-intent-04: modify the use case section, add the
      procedure section, and reorganize contents, 2016-07-08.</t>

      <t>draft-du-anima-an-intent-05: modify the use case section, and delete
      some sections, 2017-02-15.</t>
    </section>

    <!-- changes -->
  </middle>

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

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

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

      <?rfc include='reference.I-D.ietf-anima-autonomic-control-plane'?>

      <?rfc include='reference.I-D.ietf-anima-reference-model'?>

      <?rfc include='reference.I-D.ietf-anima-grasp'?>
    </references>
  </back>
</rfc>
