One document matched: draft-du-anima-an-intent-03.xml

<?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-03" 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>

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

		<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 definition, a hierarchy of policy levels, examples 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 definition, a hierarchy of policy levels, examples 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 fulfil 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 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.</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="Administrative Intent:">Intent that is used to manage
					the network infrastructure. (definition to be revised)</t>

					<t hangText="Service Intent:">Intent that is used to intervene the
					network services running over the network infrastructure. (definition to be revised)</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 title="Use Cases for ANIMA Intent Policy">
			<t>In this section, some use cases are introduced to clarify the
			concept of ANIMA Intent Policy.</t>

			<section anchor="singleASA" title="Role-based Intent Example">
				<t>A typical ANIMA Intent Policy can be found in <xref
				target="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.</t>

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

			</section>

			<section anchor="coordination" title="Coordination of Multiple Intents Example">
				<t>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".</t>

				<t>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.</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>
			</section>

			<section anchor="perdomain" title="Intent per Domain Example">
				<t>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>

			<section title="Scope of ANIMA intent">
				<t>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.</t>

				<t>{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.}</t>
			</section>

			<section title="ANIMA Intent Policy Hierarchy">
				<t>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.</t>

				<t>
					<list style="symbols">
						<t>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.</t>

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

						<t>There could be many Service Intents in the Autonomic Domain.</t>
					</list>
				</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, or more accurately, to a group of
				nodes that are influenced by that intent.</t>

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

				<t>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 <xref
				target="I-D.liu-anima-grasp-distribution"/>.</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, 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.</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>
			</section>

		<section anchor="format.of.Intent" title="Uniform Format of the ANIMA Intent Policy">
			<t>{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.}</t>

			<t>This section proposes a uniform intent format. It uses the tag-based
			format.</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 Service Agent.</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>{Editor Notes: JSON is one of the term candidates for the Autonomic
			Network Intent format.}</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, and
			Michael Behringer.</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>
		</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.RFC.7576'?>

			<?rfc include='reference.I-D.liu-anima-grasp-distribution'?>

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

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

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

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