< draft-bryskin-netconf-automation-yang-00.txt		draft-bryskin-netconf-automation-yang-01.txt >
	Network Working Group I. Bryskin		Network Working Group I. Bryskin
	Internet-Draft Huawei Technologies		Internet-Draft Huawei Technologies
	Intended status: Informational X. Liu		Intended status: Informational X. Liu
	Expires: August 25, 2018 Jabil		Expires: September 1, 2018 Jabil
	A. Clemm		A. Clemm
	Huawei		Huawei
	H. Birkholz		H. Birkholz
	Fraunhofer SIT		Fraunhofer SIT
	T. Zhou		T. Zhou
	Huawei		Huawei
	February 21, 2018		February 28, 2018
	Generalized Network Control Automation YANG Model		Generalized Network Control Automation YANG Model
	draft-bryskin-netconf-automation-yang-00		draft-bryskin-netconf-automation-yang-01
	Abstract		Abstract
	This document describes a YANG data model for the Generalized Network		This document describes a YANG data model for the Generalized Network
	Control Automation (GNCA), aimed to define an abstract and uniform		Control Automation (GNCA), aimed to define an abstract and uniform
	semantics for NETCONF/YANG scripts in the form of Event-Condition-		semantics for NETCONF/YANG scripts in the form of Event-Condition-
	Action (ECA) containers.		Action (ECA) containers.
	Status of This Memo		Status of This Memo
	skipping to change at page 1, line 40 ¶		skipping to change at page 1, line 40 ¶
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts is at http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on August 25, 2018.		This Internet-Draft will expire on September 1, 2018.
	Copyright Notice		Copyright Notice
	Copyright (c) 2018 IETF Trust and the persons identified as the		Copyright (c) 2018 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	skipping to change at page 2, line 19 ¶		skipping to change at page 2, line 19 ¶
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	2. Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . 3		2. Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
	3. GNCA concepts and constructs . . . . . . . . . . . . . . . . 4		3. GNCA concepts and constructs . . . . . . . . . . . . . . . . 4
	3.1. Policy Variable (PV) . . . . . . . . . . . . . . . . . . 4		3.1. Policy Variable (PV) . . . . . . . . . . . . . . . . . . 4
	3.2. ECA Event . . . . . . . . . . . . . . . . . . . . . . . . 6		3.2. ECA Event . . . . . . . . . . . . . . . . . . . . . . . . 6
	3.3. ECA Condition . . . . . . . . . . . . . . . . . . . . . . 7		3.3. ECA Condition . . . . . . . . . . . . . . . . . . . . . . 7
	3.4. ECA Action . . . . . . . . . . . . . . . . . . . . . . . 8		3.4. ECA Action . . . . . . . . . . . . . . . . . . . . . . . 9
	3.5. ECA . . . . . . . . . . . . . . . . . . . . . . . . . . . 10		3.5. ECA . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
	4. Where ECA scripts are executed? . . . . . . . . . . . . . . . 11		4. Where ECA scripts are executed? . . . . . . . . . . . . . . . 12
	5. ECA script example . . . . . . . . . . . . . . . . . . . . . 12		5. ECA script example . . . . . . . . . . . . . . . . . . . . . 13
	6. Complete Model Tree Structure . . . . . . . . . . . . . . . . 14		6. Complete Model Tree Structure . . . . . . . . . . . . . . . . 15
	7. YANG Module . . . . . . . . . . . . . . . . . . . . . . . . . 19		7. YANG Module . . . . . . . . . . . . . . . . . . . . . . . . . 21
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35		8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36
	9. Security Considerations . . . . . . . . . . . . . . . . . . . 35		9. Security Considerations . . . . . . . . . . . . . . . . . . . 36
	10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 35		10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 36
	11. References . . . . . . . . . . . . . . . . . . . . . . . . . 35		11. References . . . . . . . . . . . . . . . . . . . . . . . . . 36
	11.1. Normative References . . . . . . . . . . . . . . . . . . 35		11.1. Normative References . . . . . . . . . . . . . . . . . . 36
	11.2. Informative References . . . . . . . . . . . . . . . . . 35		11.2. Informative References . . . . . . . . . . . . . . . . . 37
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 36		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 37
	1. Introduction		1. Introduction
	NETCONF/YANG has proved to be very successful in facilitating		NETCONF/YANG has proved to be very successful in facilitating
	interactive network control paradigm, in which a network control		interactive network control paradigm, in which a network control
	application (controller) requests the network server to perform		application (controller) requests the network server to perform
	certain (re-)configurations, then, retrieves network states of		certain (re-)configurations, then, retrieves network states of
	interest, then asks for more (re-)configurations and so forth. This		interest, then asks for more (re-)configurations and so forth. This
	said, there are multiple use cases that require stringing network		said, there are multiple use cases that require stringing network
	configuration requests together with conditioning their order of		configuration requests together with conditioning their order of
	skipping to change at page 7, line 7 ¶		skipping to change at page 7, line 7 ¶
	that the whole purpose of ECA scripts is to reduce as much as		that the whole purpose of ECA scripts is to reduce as much as
	possible the client-server communication.		possible the client-server communication.
	All events (specified in at least one ECA pushed to the server) are		All events (specified in at least one ECA pushed to the server) are
	required to be constantly monitored by the server. One way to think		required to be constantly monitored by the server. One way to think
	of this is that the server subscribes to its own publications with		of this is that the server subscribes to its own publications with
	respect to all events that are associated with at least one ECA.		respect to all events that are associated with at least one ECA.
	3.3. ECA Condition		3.3. ECA Condition
	ECA Condition is evaluated to TRUE or FALSE logical expression		ECA Condition is evaluated to TRUE or FALSE logical expression.
	specified in a form of:		There are two ways how an ECA Condition could be specified:
			o in a form of XPath expression;
			o as a hierarchy of comparisons and logical combinations of thereof.
			The former option allows for specifying a condition of arbitrary
			complexity as a single string with an XPath expression, in which
			pertinent PVs and data store states are referred to by their
			respective positions in the YANG tree.
			The latter option allows for configuring logical hierarchies. The
			bottom of said hierarchies are primitive comparisons (micro-
			conditions) specified in a form of:
	<arg1><relation><arg2>		<arg1><relation><arg2>
	where arg1 and arg2 represent either constant/enum/identity, PV or		where arg1 and arg2 represent either constant/enum/identity, PV or
	pointed by XPath data store node or sub-tree,		pointed by XPath data store node or sub-tree,
	relation is one of the comparison operations from the set: ==, !=,		relation is one of the comparison operations from the set: ==, !=,
	>, <, >=, <=		>, <, >=, <=
	Primitive conditions could be combined hierarchically into macro-		Primitive comparisons could be combined hierarchically into macro-
	conditions via && and || logical operations.		conditions via && and || logical operations.
	(Macro-)conditions are associated with events and evaluated only		Regardless of the choice of their specification, ECA Conditions are
	within event threads triggered by the event detection.		associated with ECA Events and evaluated only within event threads
			triggered by the event detection.
	When a (macro-)condition is evaluated to TRUE, the associated with it		When an ECA Condition is evaluated to TRUE, the associated with it
	action is executed.		ECA Action is executed.
	The model structure for the ECA Condition is shown below:		The model structure for the ECA Condition is shown below:
	+--rw conditions		+--rw conditions
	| +--rw condition* [name]		| +--rw condition* [name]
	| +--rw name string		| +--rw name string
	| +--rw logical-operation-type? identityref		| +--rw (expression-choice)?
	| +--rw comparison-operation* [name]		| +--:(logical-operation)
	| | +--rw name string		| | +--rw logical-operation-type? identityref
	| | +--rw comparision-type? identityref		| | +--rw comparison-operation* [name]
	| | +--rw arg1		| | | +--rw name string
	| | | +--rw policy-argument		| | | +--rw comparision-type? identityref
	| | +--rw arg2		| | | +--rw arg1
	| | +--rw policy-argument		| | | | +--rw policy-argument
	| +--rw sub-condition* [name]		| | | | +--rw type? identityref
	| +--rw name -> /gnca/conditions/condition/name		| | | | +--rw (argument-choice)?
			| | | | +--:(policy-constant)
			| | | | | +--rw constant? string
			| | | | +--:(policy-variable)
			| | | | | +--rw policy-variable? leafref
			| | | | +--:(local-policy-variable)
			| | | | | +--rw local-policy-variable? leafref
			| | | | +--:(xpath)
			| | | | +--rw xpath? string
			| | | +--rw arg2
			| | | +--rw policy-argument
			| | | +--rw type? identityref
			| | | +--rw (argument-choice)?
			| | | +--:(policy-constant)
			| | | | +--rw constant? string
			| | | +--:(policy-variable)
			| | | | +--rw policy-variable? leafref
			| | | +--:(local-policy-variable)
			| | | | +--rw local-policy-variable? leafref
			| | | +--:(xpath)
			| | | +--rw xpath? string
			| | +--rw sub-condition* [name]
			| | +--rw name -> /gnca/conditions/condition/name
			| +--:(xpath)
			| +--rw condition-xpath? string
	The policy arguments arg1 and arg2 have the following structure:		The policy arguments arg1 and arg2 have the following structure:
	+--rw policy-argument		+--rw policy-argument
	+--rw type? identityref		+--rw type? identityref
	+--rw (argument-choice)?		+--rw (argument-choice)?
	+--:(policy-constant)		+--:(policy-constant)
	| +--rw constant? string		| +--rw constant? string
	+--:(policy-variable)		+--:(policy-variable)
	| +--rw policy-variable? leafref		| +--rw policy-variable? leafref
	skipping to change at page 9, line 26 ¶		skipping to change at page 10, line 26 ¶
	smart filter notifications do), but also the contents of global		smart filter notifications do), but also the contents of global
	and local PVs, which store results of arbitrary operations		and local PVs, which store results of arbitrary operations
	performed on the data store contents (possibly over arbitrary		performed on the data store contents (possibly over arbitrary
	period of time) to determine, for example, history/evolution of		period of time) to determine, for example, history/evolution of
	data store changes, median values, ranges and rates of the		data store changes, median values, ranges and rates of the
	changes, results of configured function calls and expressions,		changes, results of configured function calls and expressions,
	etc. - in short, any data the client may find interesting about		etc. - in short, any data the client may find interesting about
	the associated event with all the logic to compute said data		the associated event with all the logic to compute said data
	delegated to the server.		delegated to the server.
	Multiple (macro-)condition/action pairs could be combined into a		Multiple ECA Condition/Action pairs could be combined into a macro-
	macro-action (transaction).		action.
	Multiple (trans)actions could be triggered by a single event.		Multiple ECA (macro-)Actions could be triggered by a single ECA
			event.
	A (macro-)condition or a (trans)action could be defined once,		Any given ECA Condition or Action may appear in more than one ECAs.
	assigned with a name and specified in multiple ECAs.
	The model structure for the ECA Action is shown below:		The model structure for the ECA Action is shown below:
	+--rw actions		+--rw actions
	| +--rw action* [name]		| +--rw action* [name]
	| +--rw name string		| +--rw name string
	| +--rw action-element* [name]		| +--rw action-element* [name]
	| | +--rw name string		| | +--rw name string
	| | +--rw action-type? identityref		| | +--rw action-type? identityref
	| | +--rw (action-operation)?		| | +--rw (action-operation)?
	skipping to change at page 15, line 19 ¶		skipping to change at page 16, line 19 ¶
	| +--rw name string		| +--rw name string
	| +--rw (type-choice)?		| +--rw (type-choice)?
	| | +--:(common)		| | +--:(common)
	| | | +--rw type? identityref		| | | +--rw type? identityref
	| | +--:(xpath)		| | +--:(xpath)
	| | +--rw xpath? string		| | +--rw xpath? string
	| +--rw value? <anydata>		| +--rw value? <anydata>
	+--rw conditions		+--rw conditions
	| +--rw condition* [name]		| +--rw condition* [name]
	| +--rw name string		| +--rw name string
	| +--rw logical-operation-type? identityref		| +--rw (expression-choice)?
	| +--rw comparison-operation* [name]		| +--:(logical-operation)
	| | +--rw name string		| | +--rw logical-operation-type? identityref
	| | +--rw comparision-type? identityref		| | +--rw comparison-operation* [name]
	| | +--rw arg1		| | | +--rw name string
	| | | +--rw policy-argument		| | | +--rw comparision-type? identityref
	| | | +--rw type? identityref		| | | +--rw arg1
	| | | +--rw (argument-choice)?		| | | | +--rw policy-argument
	| | | +--:(policy-constant)		| | | | +--rw type?
	| | | | +--rw constant? string		identityref
	| | | +--:(policy-variable)		| | | | +--rw (argument-choice)?
	| | | | +--rw policy-variable? leafref		| | | | +--:(policy-constant)
	| | | +--:(local-policy-variable)		| | | | | +--rw constant?
	| | | | +--rw local-policy-variable? leafref		string
	| | | +--:(xpath)		| | | | +--:(policy-variable)
	| | | +--rw xpath? string		| | | | | +--rw policy-variable?
	| | +--rw arg2		leafref
	| | +--rw policy-argument		| | | | +--:(local-policy-variable)
	| | +--rw type? identityref		| | | | | +--rw local-policy-variable?
	| | +--rw (argument-choice)?		leafref
	| | +--:(policy-constant)		| | | | +--:(xpath)
	| | | +--rw constant? string		| | | | +--rw xpath?
	| | +--:(policy-variable)		string
	| | | +--rw policy-variable? leafref		| | | +--rw arg2
	| | +--:(local-policy-variable)		| | | +--rw policy-argument
	| | | +--rw local-policy-variable? leafref		| | | +--rw type?
	| | +--:(xpath)		identityref
	| | +--rw xpath? string		| | | +--rw (argument-choice)?
	| +--rw sub-condition* [name]		| | | +--:(policy-constant)
	| +--rw name -> /gnca/conditions/condition/name		| | | | +--rw constant?
			string
			| | | +--:(policy-variable)
			| | | | +--rw policy-variable?
			leafref
			| | | +--:(local-policy-variable)
			| | | | +--rw local-policy-variable?
			leafref
			| | | +--:(xpath)
			| | | +--rw xpath?
			string
			| | +--rw sub-condition* [name]
			| | +--rw name -> /gnca/conditions/condition
			/name
			| +--:(xpath)
			| +--rw condition-xpath? string
	+--rw actions		+--rw actions
	| +--rw action* [name]		| +--rw action* [name]
	| +--rw name string		| +--rw name string
	| +--rw action-element* [name]		| +--rw action-element* [name]
	| | +--rw name string		| | +--rw name string
	| | +--rw action-type? identityref		| | +--rw action-type? identityref
	| | +--rw (action-operation)?		| | +--rw (action-operation)?
	| | +--:(action)		| | +--:(action)
	| | | +--rw action-name?		| | | +--rw action-name?
	| | | -> /gnca/actions/action/name		| | | -> /gnca/actions/action/name
	skipping to change at page 19, line 39 ¶		skipping to change at page 21, line 7 ¶
	+--rw eca-scripts		+--rw eca-scripts
	| +--rw eca-script* [script-name]		| +--rw eca-script* [script-name]
	| +--rw script-name string		| +--rw script-name string
	| +--rw eca* [eca-name]		| +--rw eca* [eca-name]
	| +--rw eca-name -> /gnca/ecas/eca/name		| +--rw eca-name -> /gnca/ecas/eca/name
	+--rw running-script?		+--rw running-script?
	-> /gnca/eca-scripts/eca-script/script-name		-> /gnca/eca-scripts/eca-script/script-name
	7. YANG Module		7. YANG Module
	<CODE BEGINS> file "ietf-gnca@2018-02-20.yang"		<CODE BEGINS> file "ietf-gnca@2018-02-28.yang"
	module ietf-gnca {		module ietf-gnca {
	yang-version 1.1;		yang-version 1.1;
	namespace "urn:ietf:params:xml:ns:yang:ietf-gnca";		namespace "urn:ietf:params:xml:ns:yang:ietf-gnca";
	prefix "gnca";		prefix "gnca";
	import ietf-yang-types {		import ietf-yang-types {
	prefix "yang";		prefix "yang";
	}		}
	organization		organization
	"IETF Network Configuration (NETCONF) Working Group";		"IETF Network Configuration (NETCONF) Working Group";
	contact		contact
	"WG Web: <http://tools.ietf.org/wg/netconf/>		"WG Web: <http://tools.ietf.org/wg/netconf/>
	WG List: <mailto:netconf@ietf.org>		WG List: <mailto:netconf@ietf.org>
	Editor: Igor Bryskin		Editor: Igor Bryskin
	<mailto:Igor.Bryskin@huawei.com>		<mailto:Igor.Bryskin@huawei.com>
	Editor: Xufeng Liu		Editor: Xufeng Liu
	<mailto:Xufeng_Liu@jabil.com>		<mailto:Xufeng_Liu@jabil.com>
	Editor: Alexander Clemm		Editor: Alexander Clemm
	<mailto:ludwig@clemm.org>";		<mailto:ludwig@clemm.org>";
	description		description
	"Event Condition Action (ECA) model.";		"Event Condition Action (ECA) model.";
	revision 2018-02-20 {		revision 2018-02-28 {
	description "Initial revision";		description "Initial revision";
	reference "RFC XXXX";		reference "RFC XXXX";
	}		}
	/*		/*
	* Typedefs		* Typedefs
	*/		*/
	identity argument-type {		identity argument-type {
	description		description
	"Possible values are:		"Possible values are:
	skipping to change at page 22, line 12 ¶		skipping to change at page 23, line 26 ¶
	description		description
	"A common policy variable type, defined as an		"A common policy variable type, defined as an
	identity.";		identity.";
	}		}
	}		}
	case xpath {		case xpath {
	leaf xpath {		leaf xpath {
	type string;		type string;
	description		description
	"A XPath string, referencing a schema node, whose		"A XPath string, referencing a schema node, whose
	type is used as the type of the policy variable";		type is used as the type of the policy variable.";
	}		}
	}		}
	}		}
	anydata value {		anydata value {
	description		description
	"The value of the policy variable, in a format that is		"The value of the policy variable, in a format that is
	determined by the policy type.";		determined by the policy type.";
	}		}
	} // policy-variable-attributes		} // policy-variable-attributes
	skipping to change at page 27, line 4 ¶		skipping to change at page 28, line 18 ¶
	}		}
	} // policy-variables		} // policy-variables
	container conditions {		container conditions {
	description		description
	"Container of ECA Conditions.";		"Container of ECA Conditions.";
	list condition {		list condition {
	key name;		key name;
	description		description
	"A list of ECA Conditions.";		"A list of ECA Conditions.";
	leaf name {		leaf name {
	type string;		type string;
	description		description
	"A string name to uniquely identify an ECA Condition		"A string name to uniquely identify an ECA Condition
	globally.";		globally.";
	}		}
	leaf logical-operation-type {		choice expression-choice {
	type identityref {
	base logical-operation-type;
	}
	description
	"The logical operation type used to combine the results
	from the list comparison-operation and the list
	sub-condition, defined below.";
	}
	list comparison-operation {
	key name;
	description		description
	"A list of comparison oprations, each of them defines a		"The choices of expression format to specify a condition,
	comparison in the form of <arg1><relation><arg2>,		which can be either a XPath string or a YANG logical
	where <arg1> and <arg2> are policy arguments, while		operation structure.";
	<relation> is the comparison-type, which can be		case logical-operation {
	==, !=, >, <, >=, <=";		leaf logical-operation-type {
	leaf name {		type identityref {
	type string;		base logical-operation-type;
	description		}
	"A string name to uniquely identify a comparison		description
	operation.";		"The logical operation type used to combine the
	}		results from the list comparison-operation and the
	leaf comparision-type {		list sub-condition, defined below.";
	type identityref {
	base comparison-type;
	}		}
	description		list comparison-operation {
	"The comparison operation applied to the two arguments		key name;
	arg1 and arg2 defined blow.";		description
	}		"A list of comparison oprations, each of them defines
	container arg1 {		a comparison in the form of <arg1><relation><arg2>,
	description		where <arg1> and <arg2> are policy arguments, while
	"The policy argument used as the first parameter of		<relation> is the comparison-type, which can be
	the comparison opration.		==, !=, >, <, >=, <=";
	A policy argument represents either a constant, PV or		leaf name {
	data store value pointed by XPath.";		type string;
	uses policy-argument;		description
	}		"A string name to uniquely identify a comparison
	container arg2 {		operation.";
	description
	"The policy argument used as the secone parameter of		}
	the comparison opration.		leaf comparision-type {
	A policy argument represents either a constant, PV or		type identityref {
	data store value pointed by XPath.";		base comparison-type;
	uses policy-argument;		}
	}		description
	}		"The comparison operation applied to the two
	list sub-condition {		arguments arg1 and arg2 defined blow.";
	key name;		}
	description		container arg1 {
	"A list of sub conditions applied by the		description
	logical-operation-type. This list of sub conditions		"The policy argument used as the first parameter of
	provides the capability of hierarchically combining		the comparison opration.
	conditions.";		A policy argument represents either a constant, PV
	leaf name {		or data store value pointed by XPath.";
	type leafref {		uses policy-argument;
	path "/gnca/conditions/condition/name";		}
			container arg2 {
			description
			"The policy argument used as the secone parameter
			of the comparison opration.
			A policy argument represents either a constant, PV
			or data store value pointed by XPath.";
			uses policy-argument;
			}
	}		}
	description		list sub-condition {
	"A reference to a defined condition, which is used		key name;
	as a sub-condition for the logical operation at this		description
	hierarchy level.";		"A list of sub conditions applied by the
	}		logical-operation-type. This list of sub conditions
	} // sub-condition		provides the capability of hierarchically combining
			conditions.";
			leaf name {
			type leafref {
			path "/gnca/conditions/condition/name";
			}
			description
			"A reference to a defined condition, which is used
			as a sub-condition for the logical operation at
			this hierarchy level.";
			}
			} // sub-condition
			} // logical-operation
			case xpath {
			leaf condition-xpath {
			type string;
			description
			"A XPath string, representing a logical expression,
			which can contain comparisons of datastore values
			and logical operations in the XPath format.";
			}
			} // xpath
			} // expression-choice
	} // condition		} // condition
	} // conditions		} // conditions
	container actions {		container actions {
	description		description
	"Container of ECA Actions.";		"Container of ECA Actions.";
	list action {		list action {
	key name;		key name;
	description		description
	"A list of ECA Actions.";		"A list of ECA Actions.";
End of changes. 23 change blocks.
	135 lines changed or deleted		206 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/