ANIMA Intent Policy and Format
draft-du-anima-an-intent-03
The information below is for an old version of the document.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Zongpeng Du , Sheng Jiang , Jéferson Campos Nobre , Laurent Ciavaglia | ||
| Last updated | 2016-03-21 | ||
| Stream | (None) | ||
| Formats | plain text xml pdf htmlized pdfized bibtex | ||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-du-anima-an-intent-03
ANIMA WG Z. Du
Internet-Draft S. Jiang
Intended status: Informational Huawei Technologies Co., Ltd
Expires: September 22, 2016 J. Nobre
Federal University of Rio Grande do Sul
L. Ciavaglia
Alcatel Lucent
March 21, 2016
ANIMA Intent Policy and Format
draft-du-anima-an-intent-03
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 definition, a
hierarchy of policy levels, examples 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 September 22, 2016.
Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved.
Du, et al. Expires September 22, 2016 [Page 1]
Internet-Draft ANIMA Intent Policy March 2016
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. Use Cases for ANIMA Intent Policy . . . . . . . . . . . . . . 4
4.1. Role-based Intent Example . . . . . . . . . . . . . . . . 4
4.2. Coordination of Multiple Intents Example . . . . . . . . 5
4.3. Intent per Domain Example . . . . . . . . . . . . . . . . 5
5. Scope of ANIMA intent . . . . . . . . . . . . . . . . . . . . 6
6. ANIMA Intent Policy Hierarchy . . . . . . . . . . . . . . . . 6
7. Distribution of ANIMA Intent Policy . . . . . . . . . . . . . 6
8. Management of ANIMA Intent Policy . . . . . . . . . . . . . . 7
9. Interpretation of ANIMA Intent Policy . . . . . . . . . . . . 7
10. Uniform Format of the ANIMA Intent Policy . . . . . . . . . . 7
11. Security Considerations . . . . . . . . . . . . . . . . . . . 8
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9
14. Change log [RFC Editor: Please remove] . . . . . . . . . . . 9
15. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
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 definition, a
hierarchy of policy levels, examples 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
Du, et al. Expires September 22, 2016 [Page 2]
Internet-Draft ANIMA Intent Policy March 2016
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.
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.
Du, et al. Expires September 22, 2016 [Page 3]
Internet-Draft ANIMA Intent Policy March 2016
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. Use Cases for ANIMA Intent Policy
In this section, some use cases are introduced to clarify the concept
of ANIMA Intent Policy.
4.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
Du, et al. Expires September 22, 2016 [Page 4]
Internet-Draft ANIMA Intent Policy March 2016
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.
4.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.
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.
4.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.
Du, et al. Expires September 22, 2016 [Page 5]
Internet-Draft ANIMA Intent Policy March 2016
5. 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.}
6. 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
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.
7. 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.
Du, et al. Expires September 22, 2016 [Page 6]
Internet-Draft ANIMA Intent Policy March 2016
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].
8. 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.
{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...?). }
9. 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? }
10. 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.
Du, et al. Expires September 22, 2016 [Page 7]
Internet-Draft ANIMA Intent Policy March 2016
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.
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.}
11. 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.
Du, et al. Expires September 22, 2016 [Page 8]
Internet-Draft ANIMA Intent Policy March 2016
12. IANA Considerations
This document defines one new format. The IANA is requested to
establish a new assigned list for it.
13. Acknowledgements
The authors of this draft would like to thank the following persons
for their valuable feedback and comments: Bing Liu, Brian Carpenter,
and Michael Behringer.
This document was produced using the xml2rfc tool [RFC2629].
14. 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.
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.
15. References
[I-D.ietf-anima-autonomic-control-plane]
Behringer, M., Bjarnason, S., BL, B., and T. Eckert, "An
Autonomic Control Plane", draft-ietf-anima-autonomic-
control-plane-01 (work in progress), October 2015.
[I-D.ietf-anima-grasp]
Bormann, C., Carpenter, B., and B. Liu, "A Generic
Autonomic Signaling Protocol (GRASP)", draft-ietf-anima-
grasp-04 (work in progress), March 2016.
[I-D.ietf-anima-prefix-management]
Jiang, S., Du, Z., Carpenter, B., and Q. Qiong, "Autonomic
IPv6 Edge Prefix Management in Large-scale Networks",
draft-ietf-anima-prefix-management-00 (work in progress),
January 2016.
Du, et al. Expires September 22, 2016 [Page 9]
Internet-Draft ANIMA Intent Policy March 2016
[I-D.ietf-anima-reference-model]
Behringer, M., Carpenter, B., Eckert, T., Ciavaglia, L.,
Liu, B., Jeff, J., and J. Strassner, "A Reference Model
for Autonomic Networking", draft-ietf-anima-reference-
model-00 (work in progress), January 2016.
[I-D.liu-anima-grasp-distribution]
Liu, B. and S. Jiang, "Information Distribution over
GRASP", draft-liu-anima-grasp-distribution-00 (work in
progress), October 2015.
[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>.
[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
Du, et al. Expires September 22, 2016 [Page 10]
Internet-Draft ANIMA Intent Policy March 2016
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 September 22, 2016 [Page 11]