< draft-ietf-rtgwg-policy-model-26.txt		draft-ietf-rtgwg-policy-model-27.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: April 8, 2021 Apstra		Expires: July 14, 2021 Apstra
	A. Lindem		A. Lindem
	Cisco		Cisco
	X. Liu		X. Liu
	Volta Networks		Volta Networks
	October 5, 2020		January 10, 2021
	A YANG Data Model for Routing Policy Management		A YANG Data Model for Routing Policy
	draft-ietf-rtgwg-policy-model-26		draft-ietf-rtgwg-policy-model-27
	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. The model provides a
	operational practice. The model provides a generic policy framework		generic routing policy framework which can be extended for specific
	which can be augmented with protocol-specific policy configuration.		routing protocols using the YANG 'augment' mechanism.
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	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 April 8, 2021.		This Internet-Draft will expire on July 14, 2021.
	Copyright Notice		Copyright Notice
	Copyright (c) 2020 IETF Trust and the persons identified as the		Copyright (c) 2021 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
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	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
	skipping to change at page 2, line 42 ¶		skipping to change at page 2, line 42 ¶
	Appendix A. Routing protocol-specific policies . . . . . . . . . 36		Appendix A. Routing protocol-specific policies . . . . . . . . . 36
	Appendix B. Policy examples . . . . . . . . . . . . . . . . . . 39		Appendix B. Policy examples . . . . . . . . . . . . . . . . . . 39
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 41		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 41
	1. Introduction		1. Introduction
	This document describes a YANG [RFC7950] data model for routing		This document describes a YANG [RFC7950] data model for routing
	policy configuration based on operational usage and best practices in		policy configuration based on operational usage and best practices in
	a variety of service provider networks. The model is intended to be		a variety of service provider networks. The model is intended to be
	vendor-neutral, in order to allow operators to manage policy		vendor-neutral, in order to allow operators to manage policy
	configuration in a consistent, intuitive way in heterogeneous		configuration in a consistent way in environments with routers
	environments with routers supplied by multiple vendors.		supplied by multiple vendors.
	The YANG modules in this document conform to the Network Management		The YANG modules in this document conform to the Network Management
	Datastore Architecture (NMDA) [RFC8342].		Datastore Architecture (NMDA) [RFC8342].
	1.1. Goals and approach		1.1. Goals and approach
	This model does not aim to be feature complete -- it is a subset of		This model does not aim to be feature complete -- it is a subset of
	the policy configuration parameters available in a variety of vendor		the policy configuration parameters available in a variety of vendor
	implementations, but supports widely used constructs for managing how		implementations, but supports widely used constructs for managing how
	routes are imported, exported, and modified across different routing		routes are imported, exported, and modified across different routing
	protocols. The model development approach has been to examine actual		protocols. The model development approach has been to examine actual
	policy configurations in use across a number of operator networks.		policy configurations in use across a number of operator networks.
	Hence the focus is on enabling policy configuration capabilities and		Hence the focus is on enabling policy configuration capabilities and
	structure that are in wide use.		structure that are in wide use.
	Despite the differences in details of policy expressions and		Despite the differences in details of policy expressions and
	conventions in various vendor implementations, the model reflects the		conventions in various vendor implementations, the model reflects the
	observation that a relatively simple condition-action approach can be		observation that a relatively simple condition-action approach can be
	readily mapped to several existing vendor implementations, and also		readily mapped to several existing vendor implementations, and also
	gives operators an intuitive and straightforward way to express		gives operators a familiar and straightforward way to express policy.
	policy without sacrificing flexibility. A side effect of this design		A side effect of this design decision is that other methods for
	decision is that legacy methods for expressing policies are not		expressing policies are not considered.
	considered. Such methods could be added as an augmentation to the
	model if needed.
	Consistent with the goal to produce a data model that is vendor		Consistent with the goal to produce a data model that is vendor
	neutral, only policy expressions that are deemed to be widely		neutral, only policy expressions that are deemed to be widely
	available in existing major implementations are included in the		available in existing major implementations are included in the
	model. Those configuration items that are only available from a		model. Those configuration items that are only available from a
	single implementation are omitted from the model with the expectation		single implementation are omitted from the model with the expectation
	they will be available in separate vendor-provided modules that		they will be available in separate vendor-provided modules that
	augment the current model.		augment the current model.
	2. Terminology and Notation		2. Terminology and Notation
	skipping to change at page 6, line 39 ¶		skipping to change at page 6, line 39 ¶
	...		...
	4.1. Defined sets for policy matching		4.1. Defined sets for policy matching
	The models provide a set of generic sets that can be used for		The models provide a set of generic sets that can be used for
	matching in policy conditions. These sets are applicable for route		matching in policy conditions. These sets are applicable for route
	selection across multiple routing protocols. They may be further		selection across multiple routing protocols. They may be further
	augmented by protocol-specific models which have their own defined		augmented by protocol-specific models which have their own defined
	sets. The supported defined sets include:		sets. The supported defined sets include:
	o prefix sets - define a set of IP prefixes, each with an associated		o prefix sets - Each prefix set defines a set of IP prefixes, each
	IP prefix and netmask range (or exact length)		with an associated IP prefix and netmask range (or exact length).
	o neighbor sets - define a set of neighboring nodes by their IP		o neighbor sets - Each neighbor set define a set of neighboring
	addresses. These sets are used for selecting routes based on the		nodes by their IP addresses. A neighbor set is used for selecting
	neighbors advertising the routes.		routes based on the neighbors advertising the routes.
	o tag set - define a set of generic tag values that can be used in		o tag set - Each tag set defines a set of generic tag values that
	matches for filtering routes		can be used in matches for filtering routes.
	The model structure for defined sets is shown below.		The model structure for defined sets is shown below.
	+--rw routing-policy		+--rw routing-policy
	+--rw defined-sets		+--rw defined-sets
	| +--rw prefix-sets		| +--rw prefix-sets
	| | +--rw prefix-set* [name]		| | +--rw prefix-set* [name]
	| | +--rw name string		| | +--rw name string
	| | +--rw mode? enumeration		| | +--rw mode? enumeration
	| | +--rw prefixes		| | +--rw prefixes
	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 implementations may only support a single level		example, an implementation may only support a single level of
	of subroutine recursion. As with any routing policy construction,		subroutine recursion. As with any routing policy construction, care
	care must be taken with nested policies to ensure that the effective		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) is		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
	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-10-05.yang"		<CODE BEGINS> file "ietf-routing-policy@2021-01-10.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 14, line 15 ¶		skipping to change at page 14, line 15 ¶
	within a single routing protocol instance. This module is		within a single routing protocol instance. This module is
	intended to be used in conjunction with routing protocol		intended to be used in conjunction with routing protocol
	configuration modules (e.g., BGP) defined in other models.		configuration modules (e.g., BGP) defined in other models.
	Route policy expression:		Route policy expression:
	Policies are expressed as a set of top-level policy		Policies are expressed as a set of top-level policy
	definitions, each of which consists of a sequence of policy		definitions, each of which consists of a sequence of policy
	statements. Policy statements consist of simple		statements. Policy statements consist of simple
	condition-action tuples. Conditions may include multiple match		condition-action tuples. Conditions may include multiple match
	or comparison operations, and similarly actions may be a		or comparison operations. Actions may include changes to route
	multitude of changes to route attributes or a final		attributes as well as a final disposition of accepting or
	disposition of accepting or rejecting the route.		rejecting the route.
	Route policy evaluation:		Route policy evaluation:
	Policy definitions are referenced in routing protocol		Policy definitions are referenced in routing protocol
	configurations using import and export configuration		configurations using import and export configuration
	statements. The arguments are members of an ordered list of		statements. The arguments are members of an ordered list of
	named policy definitions which comprise a policy chain, and		named policy definitions which comprise a policy chain, and
	optionally, an explicit default policy action (i.e., reject		optionally, an explicit default policy action (i.e., reject
	or accept).		or accept).
	skipping to change at page 15, line 9 ¶		skipping to change at page 15, line 9 ¶
	policy definition which applies conditions and actions from		policy definition which applies conditions and actions from
	the referenced policy before returning to the calling policy		the referenced policy before returning to the calling policy
	statement and resuming evaluation. If the called policy		statement and resuming evaluation. If the called policy
	results in an accept-route (either explicit or by default),		results in an accept-route (either explicit or by default),
	then the subroutine returns an effective true value to the		then the subroutine returns an effective true value to the
	calling policy. Similarly, a reject-route action returns		calling policy. Similarly, a reject-route action returns
	false. If the subroutine returns true, the calling policy		false. If the subroutine returns true, the calling policy
	continues to evaluate the remaining conditions with the initial		continues to evaluate the remaining conditions with the initial
	data if route attribute values are modified.		data if route attribute values are modified.
	Copyright (c) 2020 IETF Trust and the persons identified as		Copyright (c) 2021 IETF Trust and the persons identified as
	authors of the code. All rights reserved.		authors of the code. All rights reserved.
	Redistribution and use in source and binary forms, with or		Redistribution and use in source and binary forms, with or
	without modification, is permitted pursuant to, and subject to		without modification, is permitted pursuant to, and subject to
	the license terms contained in, the Simplified BSD License set		the license terms contained in, the Simplified BSD License set
	forth in Section 4.c of the IETF Trust's Legal Provisions		forth in Section 4.c of the IETF Trust's Legal Provisions
	Relating to IETF Documents		Relating to IETF Documents
	(https://trustee.ietf.org/license-info).		(https://trustee.ietf.org/license-info).
	This version of this YANG module is part of RFC XXXX		This version of this YANG module is part of RFC XXXX
	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-10-05" {		revision "2021-01-10" {
	description		description
	"Initial revision.";		"Initial revision.";
	reference		reference
	"RFC XXXX: A YANG Data Model for Routing Policy Management.";		"RFC XXXX: A YANG Data Model for Routing Policy Management.";
	}		}
	/* Identities */		/* Identities */
	identity metric-type {		identity metric-type {
	description		description
	skipping to change at page 36, line 25 ¶		skipping to change at page 36, line 25 ¶
	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/draft-ietf-netmod-sub-		<https://datatracker.ietf.org/doc/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-10 (work in progress), November 2020.
	Appendix A. Routing protocol-specific policies		Appendix A. Routing protocol-specific policies
	Routing models that require the ability to apply routing policy may		Routing models that require the ability to apply routing policy may
	augment the routing policy model with protocol or other specific		augment the routing policy model with protocol or other specific
	policy configuration. The routing policy model assumes that		policy configuration. The routing policy model assumes that
	additional defined sets, conditions, and actions may all be added by		additional defined sets, conditions, and actions may all be added by
	other models.		other models.
	The example below provides an illustration of how another data model		The example below provides an illustration of how another data model
End of changes. 17 change blocks.
	33 lines changed or deleted		31 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/