[Docs] [txt|pdf|xml] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05

ANIMA WG                                                           Z. Du
Internet-Draft                                                  S. Jiang
Intended status: Informational              Huawei Technologies Co., Ltd
Expires: January 9, 2017                                        J. Nobre
                                 Federal University of Rio Grande do Sul
                                                            L. Ciavaglia
                                                          Alcatel Lucent
                                                            M. Behringer
                                                           Cisco Systems
                                                            July 8, 2016


                     ANIMA Intent Policy and Format
                      draft-du-anima-an-intent-04

Abstract

   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
   [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.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on January 9, 2017.







Du, et al.               Expires January 9, 2017                [Page 1]


Internet-Draft             ANIMA Intent Policy                 July 2016


Copyright Notice

   Copyright (c) 2016 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Requirements Language and Terminology . . . . . . . . . . . .   3
   3.  Concept of ANIMA Intent Policy  . . . . . . . . . . . . . . .   4
   4.  Intent Life Cycle . . . . . . . . . . . . . . . . . . . . . .   4
   5.  Use Cases for ANIMA Intent Policy . . . . . . . . . . . . . .   6
     5.1.  Role-based Intent Example . . . . . . . . . . . . . . . .   6
     5.2.  Coordination of Multiple Intents Example  . . . . . . . .   6
     5.3.  Intent per Domain Example . . . . . . . . . . . . . . . .   7
   6.  Scope of ANIMA intent . . . . . . . . . . . . . . . . . . . .   7
   7.  ANIMA Intent Policy Hierarchy . . . . . . . . . . . . . . . .   7
   8.  Distribution of ANIMA Intent Policy . . . . . . . . . . . . .   8
   9.  Management of ANIMA Intent Policy . . . . . . . . . . . . . .   8
   10. Interpretation of ANIMA Intent Policy . . . . . . . . . . . .   9
   11. Uniform Format of the ANIMA Intent Policy . . . . . . . . . .   9
   12. Security Considerations . . . . . . . . . . . . . . . . . . .  10
   13. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  10
   14. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  10
   15. Change log [RFC Editor: Please remove]  . . . . . . . . . . .  10
   16. References  . . . . . . . . . . . . . . . . . . . . . . . . .  11
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  12

1.  Introduction

   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
   [RFC7575] for autonomic networks by providing a more complete



Du, et al.               Expires January 9, 2017                [Page 2]


Internet-Draft             ANIMA Intent Policy                 July 2016


   definition, a life-cycle, some use cases and a tentative format of
   the ANIMA Intent Policy.

   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 fulfil the operator requirements.

   In PBM, the Policy Continuum defines the levels at which the policies
   are defined (policy creation point), consumed (policy execution
   point) and translated (policy refinement 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.

   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.

   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.

2.  Requirements Language and Terminology

   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
   [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 [RFC2119] key
   words.

   Autonomic Function:  A feature or function which requires no
      configuration, and can derive all required information either
      through self-knowledge, discovery or through Intent.

   Autonomic Node:  A node which employs exclusively Autonomic
      Functions.

   Legacy Node:  A non-autonomic node, i.e., a node which employs some
      non-autonomic functions.





Du, et al.               Expires January 9, 2017                [Page 3]


Internet-Draft             ANIMA Intent Policy                 July 2016


   Autonomic Network:  A network containing exclusively Autonomic Nodes.
      It may contain one or several Autonomic Domains.

   Autonomic Domain:  A collection of autonomic nodes that instantiate
      the same Intent.

   Autonomic Service Agent:  An agent implemented on an Autonomic Node
      which implements an Autonomic Function.

   Intent:  An abstract, high-level policy used to operate the network.

   ANIMA Intent Policy:  A declarative type of policy used in Autonomic
      Networks.

   Administrative Intent:  Intent that is used to manage the network
      infrastructure. (definition to be revised)

   Service Intent:  Intent that is used to intervene the network
      services running over the network infrastructure.  (definition to
      be revised)

3.  Concept of ANIMA Intent Policy

   In the scope of autonomic networking, the definition of intent can be
   found in [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."

   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).

4.  Intent Life Cycle

   This section describes a top-down flow about how an ANIMA Intent
   Policy is derived through an autonomic network.

   1.   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.



Du, et al.               Expires January 9, 2017                [Page 4]


Internet-Draft             ANIMA Intent Policy                 July 2016


   2.   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".

   3.   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.

   4.   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".

   5.   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.

   6.   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"

   7.   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.

   8.   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.



Du, et al.               Expires January 9, 2017                [Page 5]


Internet-Draft             ANIMA Intent Policy                 July 2016


   9.   Applying the target configlet.

   10.  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).

5.  Use Cases for ANIMA Intent Policy

   In this section, some use cases are introduced to clarify the concept
   of ANIMA Intent Policy.

5.1.  Role-based Intent Example

   A typical ANIMA Intent Policy can be found in
   [I-D.ietf-anima-prefix-management].  It is suggested that the prefix
   lengths for the CSG, ASG, RSG (different roles in IP RAN) can be
   assigned as an "intent".  The information carried in the intent are
   distributed in the autonomic domain to influence the detail
   configurations on each autonomic node.

   Intent could perfectly well cover a high level policy such as "all
   nodes of type x do this; type y does that".  However, it should not
   be abused.  For example, policies like "node 17: here is your CLI;
   node 23: here is your CLI; node 37: here is your CLI" should not be
   considered as an intent.

5.2.  Coordination of Multiple Intents Example

   This 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".

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






Du, et al.               Expires January 9, 2017                [Page 6]


Internet-Draft             ANIMA Intent Policy                 July 2016


   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.

5.3.  Intent per Domain Example

   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.

   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).

   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.

6.  Scope of ANIMA intent

   In the development of ASAs, some network-level parameters for a
   specific autonomic function can also be defined in an ANIMA Intent
   Policy.  GRASP is a candidate protocol for distributing and
   synchronizing these ASA parameters (or ANIMA Intent Policies) after
   the definition by human administrators.

   {Editor Notes: it is still at a preliminary stage, and the owner of
   an autonomic function should decide what is needed when the autonomic
   function is developed.  A better understanding of what Intent can and
   cannot contain requires more research and experience.  At this moment
   we include any item (parameter, policy, etc) which should be flooded
   across the network.}

7.  ANIMA Intent Policy Hierarchy

   The Autonomic Networks are supposed to be self-managed.  It includes
   managing the network infrastructure, and also the network services
   that are running over the network infrastructure.  However, the
   network services have different features against network
   administration, as listed below.  Hence, it may be better introduce a



Du, et al.               Expires January 9, 2017                [Page 7]


Internet-Draft             ANIMA Intent Policy                 July 2016


   hierarchy and to organize them into separated Administrative
   (Network) Intent and Service Intent.

   o  A Service Intent has a different scope than the Administrative
      Intent because only the nodes related to the service need to know
      this intent.  Although it may only affect a few nodes, the Service
      Intent may also be propagated domain wide.

   o  A Service Intent may have a limited lifetime, while the
      Administrative Intents are normally permanent although the content
      of the Administrative Intent may be updated from time to time.

   o  There could be many Service Intents in the Autonomic Domain.

8.  Distribution of ANIMA Intent Policy

   The distribution of intent can be done by using GRASP
   [I-D.ietf-anima-grasp] and ACP
   [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, or more accurately, to a group of
   nodes that are influenced by that intent.

   Another scenario is that when a new node joins into an autonomic
   domain, it may receive an intent from its neighbor.

   As mentioed in Section 3.1, the intent may consist of different
   parts, so that partial updating should also be supported.  Detailed
   mechanisms for intent distribution can be found in
   [I-D.liu-anima-grasp-distribution].

9.  Management of ANIMA Intent Policy

   Every Autonomic Node in the Autonomic domain should own an intent
   with the same version.  Any updating of intent, even partial
   updating, 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.

   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.





Du, et al.               Expires January 9, 2017                [Page 8]


Internet-Draft             ANIMA Intent Policy                 July 2016


   {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...?). }

10.  Interpretation of ANIMA Intent Policy

   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.

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

11.  Uniform Format of the ANIMA Intent Policy

   {Editor Notes: It is still remaining an open issue for the way that
   intent may be organized.  Should the intent be a single one in a
   given AN domain with a hierarchical version, or multiple intents,
   each of which targets different Autonomic Service Agent?  For now,
   the below text takes the later approach.}

   This section proposes a uniform intent format.  It uses the tag-based
   format.

   Autonomic intent:  The root tag for the Autonomic Network Intent.

   Intent type:  It indicates the intent type, which is associated with
      a specific Autonomic Service Agent.

   Autonomic domain:  It indicates the domain of the Autonomic Network.
      It is also the scope of the Autonomic Network Intent.

   Intent version:  It indicates the version of the ANIMA Intent Policy.
      This is an important feature for synchronization.

   Model version:  The version of the model used to define the intent.

   Name:  The name of the intent which describes the intent for human
      operators.

   Signature:  The signature is used as a security mechanism to provide
      authentication, integrity, and non-repudiation.





Du, et al.               Expires January 9, 2017                [Page 9]


Internet-Draft             ANIMA Intent Policy                 July 2016


   Timestamp:  The timestamp of the creation of the intent using the
      format supported by the IETF [TBC].

   Lifetime:  The lifetime in which the intent may be observed.  A
      special case of the lifetime is the definition of permanent
      intents.

   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.

   {Editor Notes: JSON is one of the term candidates for the Autonomic
   Network Intent format.}

12.  Security Considerations

   Relevant security issues are discussed in [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.

13.  IANA Considerations

   This document defines one new format.  The IANA is requested to
   establish a new assigned list for it.

14.  Acknowledgements

   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 M.  Halpern, John Strassner, and Jason
   Coleman.

   This document was produced using the xml2rfc tool [RFC2629].

15.  Change log [RFC Editor: Please remove]

   draft-du-anima-an-intent-00: original version, 2015-06-11.

   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.





Du, et al.               Expires January 9, 2017               [Page 10]


Internet-Draft             ANIMA Intent Policy                 July 2016


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

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

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

16.  References

   [I-D.ietf-anima-autonomic-control-plane]
              Behringer, M., Eckert, T., and S. Bjarnason, "An Autonomic
              Control Plane", draft-ietf-anima-autonomic-control-
              plane-03 (work in progress), July 2016.

   [I-D.ietf-anima-grasp]
              Bormann, D., Carpenter, B., and B. Liu, "A Generic
              Autonomic Signaling Protocol (GRASP)", draft-ietf-anima-
              grasp-06 (work in progress), June 2016.

   [I-D.ietf-anima-prefix-management]
              Jiang, S., Du, Z., Carpenter, B., and Q. Sun, "Autonomic
              IPv6 Edge Prefix Management in Large-scale Networks",
              draft-ietf-anima-prefix-management-01 (work in progress),
              July 2016.

   [I-D.ietf-anima-reference-model]
              Behringer, M., Carpenter, B., Eckert, T., Ciavaglia, L.,
              Pierre, P., Liu, B., Nobre, J., and J. Strassner, "A
              Reference Model for Autonomic Networking", draft-ietf-
              anima-reference-model-02 (work in progress), July 2016.

   [I-D.liu-anima-grasp-distribution]
              Liu, B. and S. Jiang, "Information Distribution over
              GRASP", draft-liu-anima-grasp-distribution-01 (work in
              progress), March 2016.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <http://www.rfc-editor.org/info/rfc2119>.

   [RFC2629]  Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,
              DOI 10.17487/RFC2629, June 1999,
              <http://www.rfc-editor.org/info/rfc2629>.





Du, et al.               Expires January 9, 2017               [Page 11]


Internet-Draft             ANIMA Intent Policy                 July 2016


   [RFC7575]  Behringer, M., Pritikin, M., Bjarnason, S., Clemm, A.,
              Carpenter, B., Jiang, S., and L. Ciavaglia, "Autonomic
              Networking: Definitions and Design Goals", RFC 7575,
              DOI 10.17487/RFC7575, June 2015,
              <http://www.rfc-editor.org/info/rfc7575>.

   [RFC7576]  Jiang, S., Carpenter, B., and M. Behringer, "General Gap
              Analysis for Autonomic Networking", RFC 7576,
              DOI 10.17487/RFC7576, June 2015,
              <http://www.rfc-editor.org/info/rfc7576>.

Authors' Addresses

   Zongpeng Du
   Huawei Technologies Co., Ltd
   Q14, Huawei Campus, No.156 Beiqing Road
   Hai-Dian District, Beijing, 100095
   P.R. China

   Email: duzongpeng@huawei.com


   Sheng Jiang
   Huawei Technologies Co., Ltd
   Q14, Huawei Campus, No.156 Beiqing Road
   Hai-Dian District, Beijing, 100095
   P.R. China

   Email: jiangsheng@huawei.com


   Jeferson Campos Nobre
   Federal University of Rio Grande do Sul
   Porto Alegre
   Brazil

   Email: jcnobre@inf.ufrgs.br


   Laurent Ciavaglia
   Alcatel Lucent
   Route de Villejust
   Nozay 91620
   France

   Email: laurent.ciavaglia@alcatel-lucent.com





Du, et al.               Expires January 9, 2017               [Page 12]


Internet-Draft             ANIMA Intent Policy                 July 2016


   Michael Behringer
   Cisco Systems
   Building D, 45 Allee des Ormes
   Mougins 06250
   France

   Email: mbehring@cisco.com












































Du, et al.               Expires January 9, 2017               [Page 13]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/