< draft-ietf-rtgwg-policy-model-25.txt		draft-ietf-rtgwg-policy-model-26.txt >
	RTGWG Y. Qu		RTGWG Y. Qu
	Internet-Draft Futurewei		Internet-Draft Futurewei
	Intended status: Standards Track J. Tantsura		Intended status: Standards Track J. Tantsura
	Expires: March 22, 2021 Apstra		Expires: April 8, 2021 Apstra
	A. Lindem		A. Lindem
	Cisco		Cisco
	X. Liu		X. Liu
	Volta Networks		Volta Networks
	September 18, 2020		October 5, 2020
	A YANG Data Model for Routing Policy Management		A YANG Data Model for Routing Policy Management
	draft-ietf-rtgwg-policy-model-25		draft-ietf-rtgwg-policy-model-26
	Abstract		Abstract
	This document defines a YANG data model for configuring and managing		This document defines a YANG data model for configuring and managing
	routing policies in a vendor-neutral way and based on actual		routing policies in a vendor-neutral way and based on actual
	operational practice. The model provides a generic policy framework		operational practice. The model provides a generic policy framework
	which can be augmented with protocol-specific policy configuration.		which can be augmented with protocol-specific policy configuration.
	Status of This Memo		Status of This Memo
	skipping to change at page 1, line 38 ¶		skipping to change at page 1, line 38 ¶
	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 https://datatracker.ietf.org/drafts/current/.		Drafts is at https://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 March 22, 2021.		This Internet-Draft will expire on April 8, 2021.
	Copyright Notice		Copyright Notice
	Copyright (c) 2020 IETF Trust and the persons identified as the		Copyright (c) 2020 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
	(https://trustee.ietf.org/license-info) in effect on the date of		(https://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 15 ¶		skipping to change at page 2, line 15 ¶
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	1.1. Goals and approach . . . . . . . . . . . . . . . . . . . 3		1.1. Goals and approach . . . . . . . . . . . . . . . . . . . 3
	2. Terminology and Notation . . . . . . . . . . . . . . . . . . 3		2. Terminology and Notation . . . . . . . . . . . . . . . . . . 3
	2.1. Tree Diagrams . . . . . . . . . . . . . . . . . . . . . . 4		2.1. Tree Diagrams . . . . . . . . . . . . . . . . . . . . . . 4
	2.2. Prefixes in Data Node Names . . . . . . . . . . . . . . . 4		2.2. Prefixes in Data Node Names . . . . . . . . . . . . . . . 5
	3. Model overview . . . . . . . . . . . . . . . . . . . . . . . 5		3. Model overview . . . . . . . . . . . . . . . . . . . . . . . 5
	4. Route policy expression . . . . . . . . . . . . . . . . . . . 5		4. Route policy expression . . . . . . . . . . . . . . . . . . . 6
	4.1. Defined sets for policy matching . . . . . . . . . . . . 6		4.1. Defined sets for policy matching . . . . . . . . . . . . 6
	4.2. Policy conditions . . . . . . . . . . . . . . . . . . . . 7		4.2. Policy conditions . . . . . . . . . . . . . . . . . . . . 7
	4.3. Policy actions . . . . . . . . . . . . . . . . . . . . . 8		4.3. Policy actions . . . . . . . . . . . . . . . . . . . . . 8
	4.4. Policy subroutines . . . . . . . . . . . . . . . . . . . 9		4.4. Policy subroutines . . . . . . . . . . . . . . . . . . . 9
	5. Policy evaluation . . . . . . . . . . . . . . . . . . . . . . 10		5. Policy evaluation . . . . . . . . . . . . . . . . . . . . . . 10
	6. Applying routing policy . . . . . . . . . . . . . . . . . . . 10		6. Applying routing policy . . . . . . . . . . . . . . . . . . . 10
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 11		7. Security Considerations . . . . . . . . . . . . . . . . . . . 11
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12		8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
	9. YANG module . . . . . . . . . . . . . . . . . . . . . . . . . 12		9. YANG module . . . . . . . . . . . . . . . . . . . . . . . . . 12
	9.1. Routing policy model . . . . . . . . . . . . . . . . . . 12		9.1. Routing policy model . . . . . . . . . . . . . . . . . . 12
	skipping to change at page 3, line 42 ¶		skipping to change at page 3, line 42 ¶
	augment the current model.		augment the current model.
	2. Terminology and Notation		2. Terminology and Notation
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and		"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
	"OPTIONAL" in this document are to be interpreted as described in BCP		"OPTIONAL" in this document are to be interpreted as described in BCP
	14 [RFC2119] [RFC8174] when, and only when, they appear in all		14 [RFC2119] [RFC8174] when, and only when, they appear in all
	capitals, as shown here.		capitals, as shown here.
	Routing Policy: A routing policy defines how routes are imported,		Routing policy: A routing policy defines how routes are imported,
	exported, modified, and advertised between routing protocol instances		exported, modified, and advertised between routing protocol instances
	or within a single routing protocol instance.		or within a single routing protocol instance.
			Policy chain: A policy chain is a sequence of policy definitions
			(described in Section 4). They can be referenced from different
			contexts.
			Policy statement: Policy statements consist of a set of conditions
			and actions (either of which may be empty).
	The following terms are defined in [RFC8342]:		The following terms are defined in [RFC8342]:
	o client		o client
	o server		o server
	o configuration		o configuration
	o system state		o system state
	o operational state		o operational state
	o intended configuration		o intended configuration
	The following terms are defined in [RFC7950]:		The following terms are defined in [RFC7950]:
	o action		o action
	skipping to change at page 9, line 50 ¶		skipping to change at page 9, line 50 ¶
	route disposition action is returned (i.e., boolean false for reject-		route disposition action is returned (i.e., boolean false for reject-
	route). Consequently, a subroutine cannot explicitly accept or		route). Consequently, a subroutine cannot explicitly accept or
	reject a route. Rather it merely provides an indication that 'call-		reject a route. Rather it merely provides an indication that 'call-
	policy' condition returns boolean true or false indicating whether or		policy' condition returns boolean true or false indicating whether or
	not the condition matches. Route acceptance or rejection is solely		not the condition matches. Route acceptance or rejection is solely
	determined by the top-level policy.		determined by the top-level policy.
	Note that the called policy may itself call other policies (subject		Note that the called policy may itself call other policies (subject
	to implementation limitations). The model does not prescribe a		to implementation limitations). The model does not prescribe a
	nesting depth because this varies among implementations. For		nesting depth because this varies among implementations. For
	example, some major implementation may only support a single level of		example, some major implementations may only support a single level
	subroutine recursion. As with any routing policy construction, care		of subroutine recursion. As with any routing policy construction,
	must be taken with nested policies to ensure that the effective		care must be taken with nested policies to ensure that the effective
	return value results in the intended behavior. Nested policies are a		return value results in the intended behavior. Nested policies are a
	convenience in many routing policy constructions but creating		convenience in many routing policy constructions but creating
	policies nested beyond a small number of levels (e.g., 2-3) are		policies nested beyond a small number of levels (e.g., 2-3) is
	discouraged. Also, implementations should have validation to ensure		discouraged. Also, implementations should have validation to ensure
	that there is no recursion amongst nested routing policies.		that there is no recursion amongst nested routing policies.
	5. Policy evaluation		5. Policy evaluation
	Evaluation of each policy definition proceeds by evaluating its		Evaluation of each policy definition proceeds by evaluating its
	corresponding individual policy statements in order. When all the		corresponding individual policy statements in order. When all the
	condition statements in a policy statement are satisfied, the		condition statements in a policy statement are satisfied, the
	corresponding action statements are executed. If the actions include		corresponding action statements are executed. If the actions include
	either accept-route or reject-route actions, evaluation of the		either accept-route or reject-route actions, evaluation of the
	current policy definition stops, and no further policy statement are		current policy definition stops, and no further policy statement is
	evaluated. If there are multiple policies in the policy chain,		evaluated. If there are multiple policies in the policy chain,
	subsequent policies are not evaluated. Policy chains are sequences		subsequent policies are not evaluated. Policy chains are sequences
	of policy definitions (described in . (Section 4)).		of policy definitions (described in . (Section 4)).
	If the conditions are not satisfied, then evaluation proceeds to the		If the conditions are not satisfied, then evaluation proceeds to the
	next policy statement. If none of the policy statement conditions		next policy statement. If none of the policy statement conditions
	are satisfied, then evaluation of the current policy definition		are satisfied, then evaluation of the current policy definition
	stops, and the next policy definition in the chain is evaluated.		stops, and the next policy definition in the chain is evaluated.
	When the end of the policy chain is reached, the default route		When the end of the policy chain is reached, the default route
	disposition action is performed (i.e., reject-route unless an		disposition action is performed (i.e., reject-route unless an
	skipping to change at page 11, line 16 ¶		skipping to change at page 11, line 16 ¶
	| +--rw import-policy*		| +--rw import-policy*
	| +--rw default-import-policy? default-policy-type		| +--rw default-import-policy? default-policy-type
	| +--rw export-policy*		| +--rw export-policy*
	| +--rw default-export-policy? default-policy-type		| +--rw default-export-policy? default-policy-type
	The default policy defined by the model is to reject the route for		The default policy defined by the model is to reject the route for
	both import and export policies.		both import and export policies.
	7. Security Considerations		7. Security Considerations
	The YANG modules specified in this document define a schema for data		The YANG module specified in this document defines a schema for data
	that is designed to be accessed via network management protocols such		that is designed to be accessed via network management protocols such
	as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer		as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer
	is the secure transport layer, and the mandatory-to-implement secure		is the secure transport layer, and the mandatory-to-implement secure
	transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer		transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer
	is HTTPS, and the mandatory-to-implement secure transport is TLS		is HTTPS, and the mandatory-to-implement secure transport is TLS
	[RFC8446].		[RFC8446].
	The NETCONF Access Control Model (NACM) [RFC8341] provides the means		The NETCONF Access Control Model (NACM) [RFC8341] provides the means
	to restrict access for particular NETCONF or RESTCONF users to a pre-		to restrict access for particular NETCONF or RESTCONF users to a pre-
	configured subset of all available NETCONF or RESTCONF protocol		configured subset of all available NETCONF or RESTCONF protocol
	skipping to change at page 12, line 34 ¶		skipping to change at page 12, line 34 ¶
	9. YANG module		9. YANG module
	The routing policy model is described by the YANG modules in the		The routing policy model is described by the YANG modules in the
	sections below. [RFC2328], [RFC3101], [RFC5130], and [RFC5302] are		sections below. [RFC2328], [RFC3101], [RFC5130], and [RFC5302] are
	referenced here since they are referenced in the YANG model but not		referenced here since they are referenced in the YANG model but not
	elsewhere in this document.		elsewhere in this document.
	9.1. Routing policy model		9.1. Routing policy model
	<CODE BEGINS> file "ietf-routing-policy@2020-09-18.yang"		<CODE BEGINS> file "ietf-routing-policy@2020-10-05.yang"
	module ietf-routing-policy {		module ietf-routing-policy {
	yang-version "1.1";		yang-version "1.1";
	namespace "urn:ietf:params:xml:ns:yang:ietf-routing-policy";		namespace "urn:ietf:params:xml:ns:yang:ietf-routing-policy";
	prefix rt-pol;		prefix rt-pol;
	import ietf-inet-types {		import ietf-inet-types {
	prefix "inet";		prefix "inet";
	reference "RFC 6991: Common YANG Data Types";		reference "RFC 6991: Common YANG Data Types";
	skipping to change at page 15, line 32 ¶		skipping to change at page 15, line 32 ¶
	The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL		The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL
	NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT		NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT
	RECOMMENDED', 'MAY', and 'OPTIONAL' in this document are to be		RECOMMENDED', 'MAY', and 'OPTIONAL' in this document are to be
	interpreted as described in BCP 14 (RFC 2119) (RFC 8174) when,		interpreted as described in BCP 14 (RFC 2119) (RFC 8174) when,
	and only when, they appear in all capitals, as shown here.		and only when, they appear in all capitals, as shown here.
	This version of this YANG module is part of RFC XXXX;		This version of this YANG module is part of RFC XXXX;
	see the RFC itself for full legal notices.";		see the RFC itself for full legal notices.";
	revision "2020-09-18" {		revision "2020-10-05" {
	description		description
	"Initial revision.";		"Initial revision.";
	reference		reference
	"RFC XXXX: Routing Policy Configuration Model for Service		"RFC XXXX: A YANG Data Model for Routing Policy Management.";
	Provider Networks";
	}		}
	/* Identities */		/* Identities */
	identity metric-type {		identity metric-type {
	description		description
	"Base identity for route metric types.";		"Base identity for route metric types.";
	}		}
	identity ospf-type-1-metric {		identity ospf-type-1-metric {
	skipping to change at page 22, line 4 ¶		skipping to change at page 21, line 49 ¶
	"Options that govern the behavior of a match statement. The		"Options that govern the behavior of a match statement. The
	default behavior is any, i.e., the given value matches any		default behavior is any, i.e., the given value matches any
	of the members of the defined set.";		of the members of the defined set.";
	}		}
	typedef metric-modification-type {		typedef metric-modification-type {
	type enumeration {		type enumeration {
	enum set-metric {		enum set-metric {
	description		description
	"Set the metric to the specified value.";		"Set the metric to the specified value.";
	}		}
	enum add-metric {		enum add-metric {
	description		description
	"Add the specified value to the existing metric.		"Add the specified value to the existing metric.
	If the result would overflow the maximum metric		If the result would overflow the maximum metric
	(0xffffffff), set the metric to the maximum.";		(0xffffffff), set the metric to the maximum.";
	}		}
	enum subtract-metric {		enum subtract-metric {
	description		description
	"Subtract the specified value to the existing metric. If		"Subtract the specified value from the existing metric. If
	the result would be less than 0, set the metric to 0.";		the result would be less than 0, set the metric to 0.";
	}		}
	}		}
	description		description
	"Type used to specify how to set the metric given the		"Type used to specify how to set the metric given the
	specified value.";		specified value.";
	}		}
	/* Groupings */		/* Groupings */
	skipping to change at page 22, line 43 ¶		skipping to change at page 22, line 39 ¶
	"The IP prefix represented as an IPv6 or IPv4 network		"The IP prefix represented as an IPv6 or IPv4 network
	number followed by a prefix length with an intervening		number followed by a prefix length with an intervening
	slash character as a delimiter. All members of the prefix		slash character as a delimiter. All members of the prefix
	set MUST be of the same address family as the prefix-set		set MUST be of the same address family as the prefix-set
	mode.";		mode.";
	}		}
	leaf mask-length-lower {		leaf mask-length-lower {
	type uint8;		type uint8;
	description		description
	"Mask length range lower bound. It MUST not be less than		"Mask length range lower bound. It MUST NOT be less than
	the prefix length defined in ip-prefix.";		the prefix length defined in ip-prefix.";
	}		}
	leaf mask-length-upper {		leaf mask-length-upper {
	type uint8 {		type uint8 {
	range "1..128";		range "1..128";
	}		}
	must "../mask-length-upper >= ../mask-length-lower" {		must "../mask-length-upper >= ../mask-length-lower" {
	error-message "The upper bound MUST not be less"		error-message "The upper bound MUST NOT be less"
	+ "than lower bound.";		+ "than lower bound.";
	}		}
	description		description
	"Mask length range upper bound.		"Mask length range upper bound.
	The combination of mask-length-lower and mask-length-upper		The combination of mask-length-lower and mask-length-upper
	define a range for the mask length, or single 'exact'		define a range for the mask length, or single 'exact'
	length if mask-length-lower and mask-length-upper are		length if mask-length-lower and mask-length-upper are
	equal.		equal.
	Example: 192.0.2.0/24 through 192.0.2.0/26 would be		Example: 192.0.2.0/24 through 192.0.2.0/26 would be
	skipping to change at page 24, line 41 ¶		skipping to change at page 24, line 37 ¶
	type leafref {		type leafref {
	path "/if:interfaces/if:interface/if-ext:encapsulation"		path "/if:interfaces/if:interface/if-ext:encapsulation"
	+ "/if-flex:flexible/if-flex:match"		+ "/if-flex:flexible/if-flex:match"
	+ "/if-flex:dot1q-vlan-tagged"		+ "/if-flex:dot1q-vlan-tagged"
	+ "/if-flex:outer-tag/if-flex:vlan-id";		+ "/if-flex:outer-tag/if-flex:vlan-id";
	}		}
	description		description
	"Reference to a subinterface -- this requires the base		"Reference to a subinterface -- this requires the base
	interface to be specified using the interface leaf in		interface to be specified using the interface leaf in
	this container. If only a reference to a base interface		this container. If only a reference to a base interface
	is required, this leaf SHOULD not be set.";		is required, this leaf SHOULD NOT be set.";
	}		}
	description		description
	"Container for interface match conditions";		"Container for interface match conditions";
	}		}
	}		}
	grouping match-route-type-condition {		grouping match-route-type-condition {
	description		description
	"This grouping provides route-type match condition";		"This grouping provides route-type match condition";
	skipping to change at page 34, line 17 ¶		skipping to change at page 34, line 15 ¶
	Thanks to Mahesh Jethanandani, John Scudder, Chris Bower and Tom		Thanks to Mahesh Jethanandani, John Scudder, Chris Bower and Tom
	Petch for their reviews and comments.		Petch for their reviews and comments.
	11. References		11. References
	11.1. Normative references		11.1. Normative references
	[INTF-EXT-YANG]		[INTF-EXT-YANG]
	Wilton, R., Ball, D., tapsingh@cisco.com, t., and S.		Wilton, R., Ball, D., tapsingh@cisco.com, t., and S.
	Sivaraj,, "Common Interface Extension YANG Data Models",		Sivaraj,, "Common Interface Extension YANG Data Models",
	2019, <https://datatracker.ietf.org/doc/		2019, <https://datatracker.ietf.org/doc/draft-ietf-netmod-
	draft-ietf-netmod-intf-ext-yang/>.		intf-ext-yang/>.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119,		Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997,		DOI 10.17487/RFC2119, March 1997,
	<https://www.rfc-editor.org/info/rfc2119>.		<https://www.rfc-editor.org/info/rfc2119>.
	[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328,		[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328,
	DOI 10.17487/RFC2328, April 1998,		DOI 10.17487/RFC2328, April 1998,
	<https://www.rfc-editor.org/info/rfc2328>.		<https://www.rfc-editor.org/info/rfc2328>.
	skipping to change at page 36, line 17 ¶		skipping to change at page 36, line 17 ¶
	DOI 10.17487/RFC8349, March 2018,		DOI 10.17487/RFC8349, March 2018,
	<https://www.rfc-editor.org/info/rfc8349>.		<https://www.rfc-editor.org/info/rfc8349>.
	[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol		[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
	Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,		Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
	<https://www.rfc-editor.org/info/rfc8446>.		<https://www.rfc-editor.org/info/rfc8446>.
	[SUB-INTF-VLAN-YANG]		[SUB-INTF-VLAN-YANG]
	Wilton, R., Ball, D., tapsingh@cisco.com, t., and S.		Wilton, R., Ball, D., tapsingh@cisco.com, t., and S.
	Sivaraj, "Sub-interface VLAN YANG Data Model", 2019,		Sivaraj, "Sub-interface VLAN YANG Data Model", 2019,
	<https://datatracker.ietf.org/doc/		<https://datatracker.ietf.org/doc/draft-ietf-netmod-sub-
	draft-ietf-netmod-sub-intf-vlan-model/>.		intf-vlan-model/>.
	11.2. Informative references		11.2. Informative references
	[I-D.ietf-idr-bgp-model]		[I-D.ietf-idr-bgp-model]
	Jethanandani, M., Patel, K., Hares, S., and J. Haas, "BGP		Jethanandani, M., Patel, K., Hares, S., and J. Haas, "BGP
	YANG Model for Service Provider Networks", draft-ietf-idr-		YANG Model for Service Provider Networks", draft-ietf-idr-
	bgp-model-09 (work in progress), June 2020.		bgp-model-09 (work in progress), June 2020.
	Appendix A. Routing protocol-specific policies		Appendix A. Routing protocol-specific policies
End of changes. 24 change blocks.
	27 lines changed or deleted		32 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/