Autonomic Network Intent and Format
draft-du-anima-an-intent-01

Abstract

This document describes the concept and consideration of the Autonomic Network Intent, and proposes a uniform format for the Autonomic Network Intent.

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

Copyright Notice

Copyright (c) 2015 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. Requirements Language and Terminology
• 3. Intervention of the Network Running by Autonomic Network Intent
• 3.1. Use Cases for Autonomic Network Intent
• 3.2. Administrative Intent and Service Intent
• 4. Uniform Format of the Autonomic Network Intent
• 5. Security Considerations
• 6. IANA Considerations
• 7. Acknowledgements
• 8. Change log [RFC Editor: Please remove]
• 9. References
• Authors' Addresses

1. Introduction

This document describes the concept and consideration of the Autonomic Network Intent, which is used to operate the Autonomic Nodes within Autonomic Networks. The background to Autonomic Network (AN) is described in [RFC7575] and [RFC7576]. A generic discovery and negotiation protocol (GDNP) is proposed by [I-D.carpenter-anima-gdn-protocol], which would be used in the propagation of the Autonomic Network Intent.

The Autonomic Network Intent should be able to be unscrambled by all Autonomic Nodes, although certain parts of contents may not be relevant to a specific Autonomic Node. The Autonomic Network Intent gives operational guidance for every Autonomic Node.

This document also proposes a generic format for Autonomic Network Intent.

The interface to receive or configure the Autonomic Network Intent is out of scope. The distribution mechanism of the Autonomic Network Intent is introduced in [I-D.liu-anima-intent-distribution].

Note in draft: This version is preliminary. In particular, many design details may be subject to change until the anima specifications become agreed.

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 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, quoted from [RFC7575].

Autonomic Network Intent:

Intent that is used to intervene the running status of the Autonomic Network.

Administrative Intent:

Intent that is used to manage the network infrastructure.

Service Intent:

Intent that is used to intervene the network services running over the network infrastructure.

3. Intervention of the Network Running by Autonomic Network Intent

The Autonomic Network is supposed to work with minimum intervention from human operators. However, it is still needed to receive some form of guidance/information/orders in order to meet specific requirements.

Upon receiving the Autonomic Network Intent, the Autonomic Node should be able to unscramble the meaning of the intent with no ambiguity, and act accordingly.

Using this intent approach, the operator can manage the network as a whole, and does not need to configure specific node(s) in the network like what happens in the traditional NMS system. In other words, the operator communicates with the Autonomic Network using an abstract or high lever intent, and the configurations of the nodes take place automatically. By replacing most of the NMS jobs, intent-based management makes the network management work much easier than before.

On the other sides, the intent-based and NMS-based management may co-exist for a long time, because autonomic behavior will be defined function by function. Similarly, at the beginning of defining the Autonomic Network Intents, the intent-based method cannot be assumed to cover every aspect of network management.

3.1. Use Cases for Autonomic Network Intent

An example of the intent can be found in [I-D.jiang-anima-prefix-management]. Other examples include what kind of IGP (such as OSPF) or what kind of transport layer technology (such as MPLS) should be used for the autonomic domain.

After these configurations in the network level, detailed configurations in every node are not needed; whereas, policy-based method will need detailed configurations for every specific node.

An Intent should contains some common information that are needed by every intent and some specific information that influence the configuration of the nodes, and the detailed content and format of the specific part should be defined under its specific application environment by other documents, such as the prefix management intent defined in [I-D.jiang-anima-prefix-management].

{Editor Notes: as autonomic functions are defined one by one, the intent should be developed at a per need basis.}

{Editor Notes: the intents introduced here look like not that abstract, however, it does help to make the network more autonomic, and reduce the configuration jobs. Maybe in future, when the autonomic node becomes more intelligent, some of the intents defined will disappear or be replaced.}

3.2. Administrative Intent and Service Intent

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 to organize them into separated Administrative Intent and Service Intent.

• A Service Intent may have a smaller 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.
• 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.
• There maybe are many Service Intents in the autonomic domain, while only one Administrative Intent for a giving Autonomic Service Agent.

{Editor notes: one possibility is to treat the Service Intent as a normal Intent for a certain Autonomic Service Agent, such as a Autonomic Service Provision Agent.}

4. Uniform Format of the Autonomic Network Intent

{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 Autonomic Network Intent. 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.}

5. Security Considerations

Relevant security issues are discussed in [I-D.carpenter-anima-gdn-protocol]. The Autonomic Network Intent requires strong security environment from the start, because it would be great risk if the Autonomic Network Intent had been maliciously tampered. The Autonomic Intent should employ a signature scheme to provide authentication, integrity, and non-repudiation.

6. IANA Considerations

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

7. Acknowledgements

Valuable comments were received from Bing Liu and Brian Carpenter.

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

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

9. References

Authors' Addresses