rfc9067.original		rfc9067.txt
	RTGWG Y. Qu		Internet Engineering Task Force (IETF) Y. Qu
	Internet-Draft Futurewei		Request for Comments: 9067 Futurewei
	Intended status: Standards Track J. Tantsura		Category: Standards Track J. Tantsura
	Expires: February 13, 2022 Microsoft		ISSN: 2070-1721 Microsoft
	A. Lindem		A. Lindem
	Cisco		Cisco
	X. Liu		X. Liu
	Volta Networks		Volta Networks
	August 12, 2021		October 2021
	A YANG Data Model for Routing Policy		A YANG Data Model for Routing Policy
	draft-ietf-rtgwg-policy-model-31
	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. The model provides a		routing policies in a vendor-neutral way. The model provides a
	generic routing policy framework which can be extended for specific		generic routing policy framework that can be extended for specific
	routing protocols using the YANG 'augment' mechanism.		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 is an Internet Standards Track document.
	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 https://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		This document is a product of the Internet Engineering Task Force
	and may be updated, replaced, or obsoleted by other documents at any		(IETF). It represents the consensus of the IETF community. It has
	time. It is inappropriate to use Internet-Drafts as reference		received public review and has been approved for publication by the
	material or to cite them other than as "work in progress."		Internet Engineering Steering Group (IESG). Further information on
			Internet Standards is available in Section 2 of RFC 7841.
	This Internet-Draft will expire on February 13, 2022.		Information about the current status of this document, any errata,
			and how to provide feedback on it may be obtained at
			https://www.rfc-editor.org/info/rfc9067.
	Copyright Notice		Copyright Notice
	Copyright (c) 2021 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
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction
	1.1. Goals and approach . . . . . . . . . . . . . . . . . . . 3		1.1. Goals and Approach
	2. Terminology and Notation . . . . . . . . . . . . . . . . . . 3		2. Terminology and Notation
	2.1. Tree Diagrams . . . . . . . . . . . . . . . . . . . . . . 4		2.1. Tree Diagrams
	2.2. Prefixes in Data Node Names . . . . . . . . . . . . . . . 4		2.2. Prefixes in Data Node Names
	3. Model overview . . . . . . . . . . . . . . . . . . . . . . . 5		3. Model Overview
	4. Route policy expression . . . . . . . . . . . . . . . . . . . 6		4. Route Policy Expression
	4.1. Defined sets for policy matching . . . . . . . . . . . . 6		4.1. Defined Sets for Policy Matching
	4.2. Policy conditions . . . . . . . . . . . . . . . . . . . . 7		4.2. Policy Conditions
	4.3. Policy actions . . . . . . . . . . . . . . . . . . . . . 8		4.3. Policy Actions
	4.4. Policy subroutines . . . . . . . . . . . . . . . . . . . 9		4.4. Policy Subroutines
	5. Policy evaluation . . . . . . . . . . . . . . . . . . . . . . 10		5. Policy Evaluation
	6. Applying routing policy . . . . . . . . . . . . . . . . . . . 10		6. Applying Routing Policy
	7. YANG Module and Tree . . . . . . . . . . . . . . . . . . . . 11		7. YANG Module and Tree
	7.1. Routing Policy Model Tree . . . . . . . . . . . . . . . . 11		7.1. Routing Policy Model Tree
	7.2. Routing policy model . . . . . . . . . . . . . . . . . . 12		7.2. Routing Policy Model
	8. Security Considerations . . . . . . . . . . . . . . . . . . . 32		8. Security Considerations
	9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34		9. IANA Considerations
	10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 34		10. References
	11. References . . . . . . . . . . . . . . . . . . . . . . . . . 34		10.1. Normative References
	11.1. Normative references . . . . . . . . . . . . . . . . . . 34		10.2. Informative References
	11.2. Informative references . . . . . . . . . . . . . . . . . 36		Appendix A. Routing Protocol-Specific Policies
	Appendix A. Routing protocol-specific policies . . . . . . . . . 36		Appendix B. Policy Examples
	Appendix B. Policy examples . . . . . . . . . . . . . . . . . . 39		Acknowledgements
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 41		Authors' Addresses
	1. Introduction		1. Introduction
	This document describes a YANG [RFC7950] data model for routing		This document describes a YANG data model [RFC7950] 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, to allow operators to manage policy configuration		vendor neutral to allow operators to manage policy configuration
	consistently in environments with routers supplied by multiple		consistently in environments with routers supplied by multiple
	vendors.		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
	the policy configuration parameters available in a variety of vendor		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 several operator networks.		policy configurations in use across several 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 a familiar and straightforward way to express policy.		gives operators a familiar and straightforward way to express policy.
	A side effect of this design decision is that other methods for		A side effect of this design decision is that other methods for
	expressing policies are not considered.		expressing policies are not considered.
	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 prevalent implementations are included in the model.
	model. Those configuration items that are only available from a		Those configuration items that are only available from a single
	single implementation are omitted from the model with the expectation		implementation are omitted from the model with the expectation they
	they will be available in separate vendor-provided modules that		will be available in separate vendor-provided modules that augment
	augment the current model.		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
	14 [RFC2119] [RFC8174] when, and only when, they appear in all		BCP 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
	or within a single routing protocol instance.		instances or within a single routing protocol instance.
	Policy chain: A policy chain is a sequence of policy definitions.		Policy chain: A policy chain is a sequence of policy definitions.
	They can be referenced from different contexts.		They can be referenced from different contexts.
	Policy statement: Policy statements consist of a set of conditions		Policy statement: Policy statements consist of a set of conditions
	and actions (either of which may be empty).		and actions (either of which may be empty).
	The following terms are defined in [RFC8342]:		The following terms are defined in [RFC8342]:
	o client		* client
	o server
	o configuration		* server
	o system state		* configuration
	o operational state		* system state
	o intended configuration		* operational state
			* intended configuration
	The following terms are defined in [RFC7950]:		The following terms are defined in [RFC7950]:
	o action		* action
	o augment		* augment
	o container		* container
	o container with presence		* container with presence
	o data model		* data model
	o data node		* data node
	o feature		* feature
	o leaf		* leaf
	o list		* list
	o mandatory node		* mandatory node
	o module		* module
	o schema tree		* schema tree
	o RPC (Remote Procedure Call) operation		* RPC (Remote Procedure Call) operation
	2.1. Tree Diagrams		2.1. Tree Diagrams
	Tree diagrams used in this document follow the notation defined in		Tree diagrams used in this document follow the notation defined in
	[RFC8340].		[RFC8340].
	2.2. Prefixes in Data Node Names		2.2. Prefixes in Data Node Names
	In this document, names of data nodes, actions, and other data model		In this document, names of data nodes, actions, and other data model
	objects are often used without a prefix, as long as it is clear from		objects are often used without a prefix if it is clear in which YANG
	the context in which YANG module each name is defined. Otherwise,		module each name is defined given the context. Otherwise, names are
	names are prefixed using the standard prefix associated with the		prefixed using the standard prefix associated with the corresponding
	corresponding YANG module, as shown in Table 1.		YANG module, as shown in Table 1.
	+--------+-----------------+-----------+		+========+=================+===========+
	| Prefix | YANG module | Reference |		| Prefix | YANG module | Reference |
	+--------+-----------------+-----------+		+========+=================+===========+
	| if | ietf-interfaces | [RFC8343] |		| if | ietf-interfaces | [RFC8343] |
	| | | |		+--------+-----------------+-----------+
	| rt | ietf-routing | [RFC8349] |		| rt | ietf-routing | [RFC8349] |
	| | | |		+--------+-----------------+-----------+
	| yang | ietf-yang-types | [RFC6991] |		| yang | ietf-yang-types | [RFC6991] |
	| | | |		+--------+-----------------+-----------+
	| inet | ietf-inet-types | [RFC6991] |		| inet | ietf-inet-types | [RFC6991] |
	+--------+-----------------+-----------+		+--------+-----------------+-----------+
	Table 1: Prefixes and Corresponding YANG Modules		Table 1: Prefixes and Corresponding
			YANG Modules
	3. Model overview		3. Model Overview
	The routing policy module has three main parts:		The routing policy module has three main parts:
	o A generic framework is provided to express policies as sets of		* A generic framework is provided to express policies as sets of
	related conditions and actions. This includes match sets and		related conditions and actions. This includes match sets and
	actions that are useful across many routing protocols.		actions that are useful across many routing protocols.
	o A structure that allows routing protocol models to add protocol-		* A structure that allows routing protocol models to add protocol-
	specific policy conditions and actions though YANG augmentations		specific policy conditions and actions through YANG augmentations
	is also provided. There is a complete example of this for BGP		is also provided. There is a complete example of this for BGP
	[RFC4271] policies in the proposed vendor-neutral BGP data model		[RFC4271] policies in the proposed vendor-neutral BGP data model
	[I-D.ietf-idr-bgp-model]. Appendix A provides an example of how		[IDR-BGP-MODEL]. Appendix A provides an example of how an
	an augmentation for BGP policies might be accomplished. Note that		augmentation for BGP policies might be accomplished. Note that
	this section is not normative as the BGP model is still evolving.		this section is not normative, as the BGP model is still evolving.
	o Finally, a reusable grouping is defined for attaching import and		* Finally, a reusable grouping is defined for attaching import and
	export rules in the context of routing configuration for different		export rules in the context of routing configuration for different
	protocols, VRFs, etc. This also enables creation of policy chains		protocols, Virtual Routing and Forwarding (VRF) instances, etc.
	and expressing default policy behavior. In this document, policy		This also enables the creation of policy chains and the expression
	chains are sequences of policy definitions that are applied in		of default policy behavior. In this document, policy chains are
	order (described in Section 4).		sequences of policy definitions that are applied in order
			(described in Section 4).
	The module makes use of the standard Internet types, such as IP		The module makes use of the standard Internet types, such as IP
	addresses, autonomous system numbers, etc., defined in RFC 6991		addresses, autonomous system numbers, etc., defined in RFC 6991
	[RFC6991].		[RFC6991].
	4. Route policy expression		4. Route Policy Expression
	Policies are expressed as a sequence of top-level policy definitions		Policies are expressed as a sequence of top-level policy definitions,
	each of which consists of a sequence of policy statements. Policy		each of which consists of a sequence of policy statements. Policy
	statements in turn consist of simple condition-action tuples.		statements in turn consist of simple condition-action tuples.
	Conditions may include multiple match or comparison operations, and		Conditions may include multiple match or comparison operations, and
	similarly, actions may include multiple changes to route attributes,		similarly, actions may include multiple changes to route attributes
	or indicate a final disposition of accepting or rejecting the route.		or indicate a final disposition of accepting or rejecting the route.
	This structure is shown below.		This structure is shown below.
	+--rw routing-policy		+--rw routing-policy
	+--ro match-modified-attributes? boolean		+--rw policy-definitions
	+--rw policy-definitions		+--ro match-modified-attributes? boolean
	+--rw policy-definition* [name]		+--rw policy-definition* [name]
	+--rw name string		+--rw name string
	+--rw statements		+--rw statements
	+--rw statement* [name]		+--rw statement* [name]
	+--rw name string		+--rw name string
	+--rw conditions		+--rw conditions
	| ...		| ...
	+--rw actions		+--rw actions
	...		...
	4.1. Defined sets for policy matching		4.1. Defined Sets for Policy Matching
	The model provides a collection of generic sets that can be used for		The model provides a collection 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 that have their own defined
	sets. The defined sets include:		sets. The defined sets include:
	o prefix sets - Each prefix set defines a set of IP prefixes, each		prefix sets: Each prefix set defines a set of IP prefixes, each with
	with an associated IP prefix and netmask range (or exact length).		an associated IP prefix and netmask range (or exact length).
	o neighbor sets - Each neighbor set defines a set of neighboring		neighbor sets: Each neighbor set defines a set of neighboring nodes
	nodes by their IP addresses. A neighbor set is used for selecting		by their IP addresses. A neighbor set is used for selecting
	routes based on the neighbors advertising the routes.		routes based on the neighbors advertising the routes.
	o tag set - Each tag set defines a set of generic tag values that		tag sets: Each tag set defines a set of generic tag values that can
	can be used in matches for filtering routes.		be used in matches for selecting 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 7, line 26 ¶		skipping to change at line 297 ¶
	| | +--rw mask-length-upper uint8		| | +--rw mask-length-upper uint8
	| +--rw neighbor-sets		| +--rw neighbor-sets
	| | +--rw neighbor-set* [name]		| | +--rw neighbor-set* [name]
	| | +--rw name string		| | +--rw name string
	| | +--rw address* inet:ip-address		| | +--rw address* inet:ip-address
	| +--rw tag-sets		| +--rw tag-sets
	| +--rw tag-set* [name]		| +--rw tag-set* [name]
	| +--rw name string		| +--rw name string
	| +--rw tag-value* tag-type		| +--rw tag-value* tag-type
	4.2. Policy conditions		4.2. Policy Conditions
	Policy statements consist of a set of conditions and actions (either		Policy statements consist of a set of conditions and actions (either
	of which may be empty). Conditions are used to match route		of which may be empty). Conditions are used to match route
	attributes against a defined set (e.g., a prefix set), or to compare		attributes against a defined set (e.g., a prefix set) or to compare
	attributes against a specific value. The default action is to		attributes against a specific value.
	reject-route.
	Match conditions may be further modified using the match-set-options		Match conditions may be further modified using the match-set-options
	configuration which allows network operators to change the behavior		configuration, which allows network operators to change the behavior
	of a match. Three options are supported:		of a match. Three options are supported:
	o ALL - match is true only if the given value matches all members of		'all': Match is true only if the given value matches all members of
	the set.		the set.
	o ANY - match is true if the given value matches any member of the		'any': Match is true if the given value matches any member of the
	set.		set.
	o INVERT - match is true if the given value does not match any		'invert': Match is true if the given value does not match any member
	member of the given set.		of the given set.
	Not all options are appropriate for matching against all defined sets		Not all options are appropriate for matching against all defined sets
	(e.g., match ALL in a prefix set does not make sense). In the model,		(e.g., match 'all' in a prefix set does not make sense). In the
	a restricted set of match options is used where applicable.		model, a restricted set of match options is used where applicable.
	Comparison conditions may similarly use options to change how route		Comparison conditions may similarly use options to change how route
	attributes should be tested, e.g., for equality or inequality,		attributes should be tested, e.g., for equality or inequality,
	against a given value.		against a given value.
	While most policy conditions will be added by individual routing		While most policy conditions will be added by individual routing
	protocol models via augmentation, this routing policy model includes		protocol models via augmentation, this routing policy model includes
	several generic match conditions and the ability to test which		several generic match conditions and the ability to test which
	protocol or mechanism installed a route (e.g., BGP, IGP, static,		protocol or mechanism installed a route (e.g., BGP, IGP, static,
	etc.). The conditions included in the model are shown below.		etc.). The conditions included in the model are shown below.
	+--rw routing-policy		+--rw routing-policy
	+--rw policy-definitions		+--rw policy-definitions
	+--rw policy-definition* [name]		+--rw policy-definition* [name]
	+--rw name string		+--rw name string
	+--rw statements		+--rw statements
	+--rw statement* [name]		+--rw statement* [name]
	+--rw conditions		+--rw conditions
	| +--rw call-policy?		| +--rw call-policy?
	| +--rw source-protocol?		| +--rw source-protocol?
	| +--rw match-interface		| +--rw match-interface
	| | +--rw interface?		| | +--rw interface?
	| +--rw match-prefix-set		| +--rw match-prefix-set
	| | +--rw prefix-set?		| | +--rw prefix-set?
	| | +--rw match-set-options?		| | +--rw match-set-options?
	| +--rw match-neighbor-set		| +--rw match-neighbor-set
	| | +--rw neighbor-set?		| | +--rw neighbor-set?
	| +--rw match-tag-set		| +--rw match-tag-set
	| | +--rw tag-set?		| | +--rw tag-set?
	| | +--rw match-set-options?		| | +--rw match-set-options?
	| +--rw match-route-type* identityref		| +--rw match-route-type
	| +--rw route-type*		| +--rw route-type*
	4.3. Policy actions		4.3. Policy Actions
	When policy conditions are satisfied, policy actions are used to set		When policy conditions are satisfied, policy actions are used to set
	various attributes of the route being processed, or to indicate the		various attributes of the route being processed or to indicate the
	final disposition of the route, i.e., accept or reject.		final disposition of the route, i.e., accept or reject.
	Similar to policy conditions, the routing policy model includes		Similar to policy conditions, the routing policy model includes
	generic actions in addition to the basic route disposition actions.		generic actions in addition to the basic route disposition actions.
	These are shown below.		These are shown below.
	+--rw routing-policy		+--rw routing-policy
	+--rw policy-definitions		+--rw policy-definitions
	+--rw policy-definition* [name]		+--rw policy-definition* [name]
	+--rw statements		+--rw statements
	+--rw statement* [name]		+--rw statement* [name]
	+--rw actions		+--rw actions
	+--rw policy-result? policy-result-type		+--rw policy-result? policy-result-type
	+--rw set-metric		+--rw set-metric
	| +--rw metric-modification?		| +--rw metric-modification?
	| | metric-modification-type		| | metric-modification-type
	| +--rw metric? uint32		| +--rw metric? uint32
	+--rw set-metric-type		+--rw set-metric-type
	| +--rw metric-type? identityref		| +--rw metric-type? identityref
	+--rw set-route-level		+--rw set-route-level
	| +--rw route-level? identityref		| +--rw route-level? identityref
	+--rw set-route-preference? uint16		+--rw set-route-preference? uint16
	+--rw set-tag? tag-type		+--rw set-tag? tag-type
	+--rw set-application-tag? tag-type		+--rw set-application-tag? tag-type
	4.4. Policy subroutines		4.4. Policy Subroutines
	Policy 'subroutines' (or nested policies) are supported by allowing		Policy 'subroutines' (or nested policies) are supported by allowing
	policy statement conditions to reference other policy definitions		policy statement conditions to reference other policy definitions
	using the call-policy configuration. Called policies apply their		using the call-policy configuration. Called policies apply their
	conditions and actions before returning to the calling policy		conditions and actions before returning to the calling policy
	statement and resuming evaluation. The outcome of the called policy		statement and resuming evaluation. The outcome of the called policy
	affects the evaluation of the calling policy. If the called policy		affects the evaluation of the calling policy. If the called policy
	results in an accept-route, then the subroutine returns an effective		results in an accept-route, then the subroutine returns an effective
	Boolean true value to the calling policy. For the calling policy,		Boolean true value to the calling policy. For the calling policy,
	this is equivalent to a condition statement evaluating to a true		this is equivalent to a condition statement evaluating to a true
	value and evaluation of the policy continues (see Section 5). Note		value, thus the calling party continues in its evaluation of the
	that the called policy may also modify attributes of the route in its		policy (see Section 5). Note that the called policy may also modify
	action statements. Similarly, a reject-route action returns false		attributes of the route in its action statements. Similarly, a
	and the calling policy evaluation will be affected accordingly. When		reject-route action returns false, and the calling policy evaluation
	the end of the subroutine policy statements is reached, the default		will be affected accordingly. When the end of the subroutine policy
	route disposition action is returned (i.e., Boolean false for reject-		statements is reached, the default route disposition action is
	route). Consequently, a subroutine cannot explicitly accept or		returned (i.e., Boolean false for reject-route). Consequently, a
	reject a route. Rather, the called policy returns Boolean true if		subroutine cannot explicitly accept or reject a route. Rather, the
	its outcome is accept-route or Boolean false if its outcome is		called policy returns Boolean true if its outcome is accept-route or
	reject-route. Route acceptance or rejection is solely determined by		Boolean false if its outcome is reject-route. Route acceptance or
	the top-level policy.		rejection is solely 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, an implementation may only support a single level of		example, an implementation may only support a single level of
	subroutine recursion. As with any routing policy construction, care		subroutine recursion. As with any routing policy construction, 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., two to three)
	discouraged. Also, implementations MUST validate to ensure that		is discouraged. Also, implementations MUST perform validation to
	there is no recursion among nested routing policies.		ensure that there is no recursion among 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
	individual policy statements in order that they are defined. When		individual policy statements in the order that they are defined.
	all the condition statements in a policy statement are satisfied, the		When all the condition statements in a policy statement are
	corresponding action statements are executed. If the actions include		satisfied, the corresponding action statements are executed. If the
	either accept-route or reject-route actions, evaluation of the		actions include either accept-route or reject-route actions,
	current policy definition stops, and no further policy statement is		evaluation of the current policy definition stops, and no further
	evaluated. If there are multiple policies in the policy chain,		policy statement is evaluated. If there are multiple policies in the
	subsequent policies are not evaluated. Policy chains are sequences		policy chain, subsequent policies are not evaluated. Policy chains
	of policy definitions (as described in Section 4).		are sequences of policy definitions (as 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
	alternate default action is specified for the chain).		alternate default action is specified for the chain).
	Whether the route's pre-policy attributes are used for testing policy		Whether the route's pre-policy attributes are used for testing policy
	statement conditions is dependent on the implementation specific		statement conditions is dependent on the implementation-specific
	value of the match-modified-attributes leaf. If match-modified-		value of the match-modified-attributes leaf. If match-modified-
	attributes is false and actions modify route attributes, these		attributes is false and actions modify route attributes, these
	modifications are not used for policy statement conditions.		modifications are not used for policy statement conditions.
	Conversely, if match-modified-attributes is true and actions modify		Conversely, if match-modified-attributes is true and actions modify
	the policy application-specific attributes, the attributes as		the policy application-specific attributes, the attributes as
	modified by the policy are used for policy condition statements.		modified by the policy are used for policy condition statements.
	6. Applying routing policy		6. Applying Routing Policy
	Routing policy is applied by defining and attaching policy chains in		Routing policy is applied by defining and attaching policy chains in
	various routing contexts. Policy chains are sequences of policy		various routing contexts. Policy chains are sequences of policy
	definitions (described in Section 4). They can be referenced from		definitions (described in Section 4). They can be referenced from
	different contexts. For example, a policy chain could be associated		different contexts. For example, a policy chain could be associated
	with a routing protocol and used to control its interaction with its		with a routing protocol and used to control its interaction with its
	protocol peers. Or it could be used to control the interaction		protocol peers, or it could be used to control the interaction
	between a routing protocol and the local routing information base. A		between a routing protocol and the local routing information base. A
	policy chain has an associated direction (import or export), with		policy chain has an associated direction (import or export) with
	respect to the context in which it is referenced.		respect to the context in which it is referenced.
	The routing policy model defines an apply-policy grouping that can be		The routing policy model defines an apply-policy grouping that can be
	imported and used by other models. As shown below, it allows		imported and used by other models. As shown below, it allows
	definition of import and export policy chains, as well as specifying		definition of import and export policy chains, as well as specifies
	the default route disposition to be used when no policy definition in		the default route disposition to be used when no policy definition in
	the chain results in a final decision.		the chain results in a final decision.
	+--rw apply-policy		+--rw apply-policy
	| +--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. YANG Module and Tree		7. YANG Module and Tree
	7.1. Routing Policy Model Tree		7.1. Routing Policy Model Tree
	The tree of the routing policy model is shown below.		The tree of the routing policy model is shown below.
	module: ietf-routing-policy		module: ietf-routing-policy
	rw routing-policy		+--rw routing-policy
	+--rw defined-sets		+--rw defined-sets
	| +--rw prefix-sets		| +--rw prefix-sets
	| | +--rw prefix-set* [name mode]		| | +--rw prefix-set* [name mode]
	| | +--rw name string		| | +--rw name string
	| | +--rw mode enumeration		| | +--rw mode enumeration
	| | +--rw prefixes		| | +--rw prefixes
	| | +--rw prefix-list* [ip-prefix mask-length-lower		| | +--rw prefix-list* [ip-prefix mask-length-lower
	| | mask-length-upper]		| | mask-length-upper]
	| | +--rw ip-prefix inet:ip-prefix		| | +--rw ip-prefix inet:ip-prefix
	| | +--rw mask-length-lower uint8		| | +--rw mask-length-lower uint8
	| | +--rw mask-length-upper uint8		| | +--rw mask-length-upper uint8
	| +--rw neighbor-sets		| +--rw neighbor-sets
	| | +--rw neighbor-set* [name]		| | +--rw neighbor-set* [name]
	| | +--rw name string		| | +--rw name string
	| | +--rw address* inet:ip-address		| | +--rw address* inet:ip-address
	| +--rw tag-sets		| +--rw tag-sets
	| +--rw tag-set* [name]		| +--rw tag-set* [name]
	| +--rw name string		| +--rw name string
	| +--rw tag-value* tag-type		| +--rw tag-value* tag-type
	+--rw policy-definitions		+--rw policy-definitions
	+--ro match-modified-attributes? boolean		+--ro match-modified-attributes? boolean
	+--rw policy-definition* [name]		+--rw policy-definition* [name]
	+--rw name string
	+--rw statements
	+--rw statement* [name]
	+--rw name string		+--rw name string
	+--rw conditions		+--rw statements
	| +--rw call-policy? -> ../../../../../..		+--rw statement* [name]
	| /policy-definitions		+--rw name string
	| /policy-definition/name		+--rw conditions
	| +--rw source-protocol? identityref		| +--rw call-policy? -> ../../../../../..
	| +--rw match-interface		| /policy-definitions
	| | +--rw interface? -> /if:interfaces/interface		| /policy-definition/name
	| | /name		| +--rw source-protocol? identityref
	| +--rw match-prefix-set		| +--rw match-interface
	| | +--rw prefix-set? -> ../../../../../../..		| | +--rw interface? if:interface-ref
	| | /defined-sets/prefix-sets		| +--rw match-prefix-set
	| | /prefix-set/name		| | +--rw prefix-set? -> ../../../../../../..
	| | +--rw match-set-options? match-set-options-type		| | /defined-sets
	| +--rw match-neighbor-set		| | /prefix-sets
	| | +--rw neighbor-set? -> ../../../../../../..		| | /prefix-set/name
	| | /defined-sets/neighbor-sets		| | +--rw match-set-options?
	| | /neighbor-set/name		| | match-set-options-type
	| +--rw match-tag-set		| +--rw match-neighbor-set
	| | +--rw tag-set? -> ../../../../../../..		| | +--rw neighbor-set? -> ../../../../../../..
	| | /defined-sets/tag-sets		| | /defined-sets
	| | /tag-set/name		| | /neighbor-sets
	| | +--rw match-set-options? match-set-options-type		| | /neighbor-set/name
	| +--rw match-route-type* identityref		| +--rw match-tag-set
	+--rw actions		| | +--rw tag-set? -> ../../../../../../..
	+--rw policy-result? policy-result-type		| | /defined-sets/tag-sets
	+--rw set-metric		| | /tag-set/name
	| +--rw metric-modification? metric-modification-type		| | +--rw match-set-options?
	| +--rw metric? uint32		| | match-set-options-type
	+--rw set-metric-type		| +--rw match-route-type
	| +--rw metric-type? identityref		| +--rw route-type* identityref
	+--rw set-route-level		+--rw actions
	| +--rw route-level? identityref		+--rw policy-result? policy-result-type
	+--rw set-route-preference? uint16		+--rw set-metric
	+--rw set-tag? tag-type		| +--rw metric-modification?
	+--rw set-application-tag? tag-type		| metric-modification-type
			| +--rw metric? uint32
			+--rw set-metric-type
			| +--rw metric-type? identityref
			+--rw set-route-level
			| +--rw route-level? identityref
			+--rw set-route-preference? uint16
			+--rw set-tag? tag-type
			+--rw set-application-tag? tag-type
	7.2. Routing policy model		7.2. Routing Policy Model
	The following RFCs are not referenced in the document text but are		The following RFCs are not referenced in the document text but are
	referenced in the ietf-routing-policy.yang module: [RFC2328],		referenced in the ietf-routing-policy.yang module: [RFC2328],
	[RFC3101], [RFC5130], [RFC5302], [RFC6991], and [RFC8343].		[RFC3101], [RFC5130], [RFC5302], [RFC6991], and [RFC8343].
	<CODE BEGINS> file "ietf-routing-policy@2021-08-12.yang"		<CODE BEGINS> file "ietf-routing-policy@2021-09-28.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 {
	prefix "inet";
	reference
	"RFC 6991: Common YANG Data Types";
	}
	import ietf-yang-types {
	prefix "yang";
	reference
	"RFC 6991: Common YANG Data Types";
	}
	import ietf-interfaces {
	prefix "if";
	reference
	"RFC 8343: A YANG Data Model for Interface
	Management (NMDA Version)";
	}
	import ietf-routing {
	prefix "rt";
	reference
	"RFC 8349: A YANG Data Model for Routing
	Management (NMDA Version)";
	}
	organization
	"IETF RTGWG - Routing Area Working Group";
	contact
	"WG Web: <https://datatracker.ietf.org/wg/rtgwg/>
	WG List: <mailto: rtgwg@ietf.org>
	Editor: Yingzhen Qu
	<mailto: yingzhen.qu@futurewei.com>
	Jeff Tantsura
	<mailto: jefftant.ietf@gmail.com>
	Acee Lindem
	<mailto: acee@cisco.com>
	Xufeng Liu
	<mailto: xufeng.liu.ietf@gmail.com>";
	description
	"This module describes a YANG model for routing policy
	configuration. It is a limited subset of all of the policy
	configuration parameters available in the variety of vendor
	implementations, but supports widely used constructs for
	managing how routes are imported, exported, modified and
	advertised across different routing protocol instances or
	within a single routing protocol instance. This module is
	intended to be used in conjunction with routing protocol
	configuration modules (e.g., BGP) defined in other models.
	This YANG module conforms to the Network Management
	Datastore Architecture (NMDA), as described in RFC 8342.
	Copyright (c) 2021 IETF Trust and the persons identified as
	authors of the code. All rights reserved.
	Redistribution and use in source and binary forms, with or
	without modification, is permitted pursuant to, and subject to
	the license terms contained in, the Simplified BSD License set
	forth in Section 4.c of the IETF Trust's Legal Provisions
	Relating to IETF Documents
	(https://trustee.ietf.org/license-info).
	This version of this YANG module is part of RFC XXXX;
	see the RFC itself for full legal notices.
	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 BCP 14 (RFC 2119) (RFC 8174) when,
	and only when, they appear in all capitals, as shown here.";
	reference "RFC XXXX: A YANG Data Model for Routing Policy.";
	revision "2021-08-12" {
	description
	"Initial revision.";
	reference
	"RFC XXXX: A YANG Data Model for Routing Policy Management.";
	}
	/* Identities */
	identity metric-type {
	description
	"Base identity for route metric types.";
	}
	identity ospf-type-1-metric {
	base metric-type;
	description
	"Identity for the OSPF type 1 external metric types. It
	is only applicable to OSPF routes.";
	reference
	"RFC 2328: OSPF Version 2";
	}
	identity ospf-type-2-metric {
	base metric-type;
	description
	"Identity for the OSPF type 2 external metric types. It
	is only applicable to OSPF routes.";
	reference
	"RFC 2328: OSPF Version 2";
	}
	identity isis-internal-metric {
	base metric-type;
	description
	"Identity for the IS-IS internal metric types. It is only
	applicable to IS-IS routes.";
	reference
	"RFC 5302: Domain-Wide Prefix Distribution with
	Two-Level IS-IS";
	}
	identity isis-external-metric {
	base metric-type;
	description
	"Identity for the IS-IS external metric types. It is only
	applicable to IS-IS routes.";
	reference
	"RFC 5302: Domain-Wide Prefix Distribution with
	Two-Level IS-IS";
	}
	identity route-level {
	description
	"Base identity for route import level.";
	}
	identity ospf-normal {
	base route-level;
	description
	"Identity for OSPF importation into normal areas
	It is only applicable to routes imported
	into the OSPF protocol.";
	reference
	"RFC 2328: OSPF Version 2";
	}
	identity ospf-nssa-only {
	base route-level;
	description
	"Identity for the OSPF Not-So-Stubby Area (NSSA) area
	importation. It is only applicable to routes imported
	into the OSPF protocol.";
	reference
	"RFC 3101: The OSPF Not-So-Stubby Area (NSSA) Option";
	}
	identity ospf-normal-nssa {
	base route-level;
	description
	"Identity for OSPF importation into both normal and NSSA
	areas, it is only applicable to routes imported into
	the OSPF protocol.";
	reference
	"RFC 3101: The OSPF Not-So-Stubby Area (NSSA) Option";
	}
	identity isis-level-1 {
	base route-level;
	description
	"Identity for IS-IS Level 1 area importation. It is only
	applicable to routes imported into the IS-IS protocol.";
	reference
	"RFC 5302: Domain-Wide Prefix Distribution with
	Two-Level IS-IS";
	}
	identity isis-level-2 {
	base route-level;
	description
	"Identity for IS-IS Level 2 area importation. It is only
	applicable to routes imported into the IS-IS protocol.";
	reference
	"RFC 5302: Domain-Wide Prefix Distribution with
	Two-Level IS-IS";
	}
	identity isis-level-1-2 {
	base route-level;
	description
	"Identity for IS-IS importation into both Level 1 and Level 2
	areas. It is only applicable to routes imported into the IS-IS
	protocol.";
	reference
	"RFC 5302: Domain-Wide Prefix Distribution with
	Two-Level IS-IS";
	}
	identity proto-route-type {
	description
	"Base identity for route type within a protocol.";
	}
	identity isis-level-1-type {
	base proto-route-type;
	description
	"Identity for IS-IS Level 1 route type. It is only
	applicable to IS-IS routes.";
	reference
	"RFC 5302: Domain-Wide Prefix Distribution with
	Two-Level IS-IS";
	}
	identity isis-level-2-type {
	base proto-route-type;
	description
	"Identity for IS-IS Level 2 route type. It is only
	applicable to IS-IS routes.";
	reference
	"RFC 5302: Domain-Wide Prefix Distribution with
	Two-Level IS-IS";
	}
	identity ospf-internal-type {
	base proto-route-type;
	description
	"Identity for OSPF intra-area or inter-area route type.
	It is only applicable to OSPF routes.";
	reference
	"RFC 2328: OSPF Version 2";
	}
	identity ospf-external-type {
	base proto-route-type;
	description
	"Identity for OSPF external type 1/2 route type.
	It is only applicable to OSPF routes.";
	reference
	"RFC 2328: OSPF Version 2";
	}
	identity ospf-external-t1-type {
	base ospf-external-type;
	description
	"Identity for OSPF external type 1 route type.
	It is only applicable to OSPF routes.";
	reference
	"RFC 2328: OSPF Version 2";
	}
	identity ospf-external-t2-type {
	base ospf-external-type;
	description
	"Identity for OSPF external type 2 route type.
	It is only applicable to OSPF routes.";
	reference
	"RFC 2328: OSPF Version 2";
	}
	identity ospf-nssa-type {
	base proto-route-type;
	description
	"Identity for OSPF NSSA type 1/2 route type.
	It is only applicable to OSPF routes.";
	reference
	"RFC 3101: The OSPF Not-So-Stubby Area (NSSA) Option";
	}
	identity ospf-nssa-t1-type {
	base ospf-nssa-type;
	description
	"Identity for OSPF NSSA type 1 route type.
	It is only applicable to OSPF routes.";
	reference
	"RFC 3101: The OSPF Not-So-Stubby Area (NSSA) Option";
	}
	identity ospf-nssa-t2-type {
	base ospf-nssa-type;
	description
	"Identity for OSPF NSSA type 2 route type.
	It is only applicable to OSPF routes.";
	reference
	"RFC 3101: The OSPF Not-So-Stubby Area (NSSA) Option";
	}
	identity bgp-internal {
	base proto-route-type;
	description
	"Identity for routes learned from internal BGP (IBGP).
	It is only applicable to BGP routes.";
	reference
	"RFC 4271: A Border Gateway Protocol 4 (BGP-4)";
	}
	identity bgp-external {
	base proto-route-type;
	description
	"Identity for routes learned from external BGP (EBGP).
	It is only applicable to BGP routes.";
	reference
	"RFC 4271: A Border Gateway Protocol 4 (BGP-4)";
	}
	/* Type Definitions */
	typedef default-policy-type {
	type enumeration {
	enum accept-route {
	description
	"Default policy to accept the route.";
	}
	enum reject-route {
	description
	"Default policy to reject the route.";
	}
	}
	description
	"Type used to specify route disposition in
	a policy chain. This typedef is used in
	the default import and export policy.";
	}
	typedef policy-result-type {
	type enumeration {
	enum accept-route {
	description
	"Policy accepts the route.";
	}
	enum reject-route {
	description
	"Policy rejects the route.";
	}
	}
	description
	"Type used to specify route disposition in
	a policy chain.";
	}
	typedef tag-type {
	type union {
	type uint32;
	type yang:hex-string;
	}
	description
	"Type for expressing route tags on a local system,
	including IS-IS and OSPF; may be expressed as either decimal
	or hexadecimal integer.";
	reference
	"RFC 2328: OSPF Version 2
	RFC 5130: A Policy Control Mechanism in IS-IS Using
	Administrative Tags";
	}
	typedef match-set-options-type {
	type enumeration {
	enum any {
	description
	"Match is true if given value matches any member
	of the defined set.";
	}
	enum all {
	description
	"Match is true if given value matches all
	members of the defined set.";
	}
	enum invert {
	description
	"Match is true if given value does not match any
	member of the defined set.";
	}
	}
	default any;
	description
	"Options that govern the behavior of a match statement. The
	default behavior is any, i.e., the given value matches any
	of the members of the defined set.";
	}
	typedef metric-modification-type {
	type enumeration {
	enum set-metric {
	description
	"Set the metric to the specified value.";
	}
	enum add-metric {
	description
	"Add the specified value to the existing metric.
	If the result overflows the maximum metric
	(0xffffffff), set the metric to the maximum.";
	}
	enum subtract-metric {
	description
	"Subtract the specified value from the existing metric. If
	the result is less than 0, set the metric to 0.";
	}
	}
	description
	"Type used to specify how to set the metric given the
	specified value.";
	}
	/* Groupings */
	grouping prefix {
	description
	"Configuration data for a prefix definition.
	The combination of mask-length-lower and mask-length-upper
	define a range for the mask length, or single 'exact'
	length if mask-length-lower and mask-length-upper are
	equal.
	Example: 192.0.2.0/24 through 192.0.2.0/26 would be		import ietf-inet-types {
	expressed as prefix: 192.0.2.0/24,		prefix inet;
	mask-length-lower=24,		reference
	mask-length-upper=26		"RFC 6991: Common YANG Data Types";
			}
			import ietf-yang-types {
			prefix yang;
			reference
			"RFC 6991: Common YANG Data Types";
			}
			import ietf-interfaces {
			prefix if;
			reference
			"RFC 8343: A YANG Data Model for Interface
			Management";
			}
			import ietf-routing {
			prefix rt;
			reference
			"RFC 8349: A YANG Data Model for Routing
			Management (NMDA Version)";
			}
	Example: 192.0.2.0/24 (an exact match) would be		organization
	expressed as prefix: 192.0.2.0/24,		"IETF RTGWG - Routing Area Working Group";
	mask-length-lower=24,		contact
	mask-length-upper=24		"WG Web: <https://datatracker.ietf.org/wg/rtgwg/>
			WG List: <mailto: rtgwg@ietf.org>
	Example: 2001:DB8::/32 through 2001:DB8::/64 would be		Editors: Yingzhen Qu
	expressed as prefix: 2001:DB8::/32,		<mailto: yingzhen.qu@futurewei.com>
	mask-length-lower=32,		Jeff Tantsura
	mask-length-upper=64";		<mailto: jefftant.ietf@gmail.com>
			Acee Lindem
			<mailto: acee@cisco.com>
			Xufeng Liu
			<mailto: xufeng.liu.ietf@gmail.com>";
			description
			"This module describes a YANG data model for routing policy
			configuration. It is a limited subset of all of the policy
			configuration parameters available in the variety of vendor
			implementations, but supports widely used constructs for
			managing how routes are imported, exported, modified, and
			advertised across different routing protocol instances or
			within a single routing protocol instance. This module is
			intended to be used in conjunction with routing protocol
			configuration modules (e.g., BGP) defined in other models.
	leaf ip-prefix {		This YANG module conforms to the Network Management
	type inet:ip-prefix;		Datastore Architecture (NMDA), as described in RFC 8342.
	mandatory true;
	description
	"The IP prefix represented as an IPv6 or IPv4 network
	number followed by a prefix length with an intervening
	slash character as a delimiter. All members of the
	prefix-set MUST be of the same address family as the
	prefix-set mode.";
	}
	leaf mask-length-lower {		The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL
	type uint8 {		NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED',
	range "0..128";		'MAY', and 'OPTIONAL' in this document are to be interpreted as
	}		described in BCP 14 (RFC 2119) (RFC 8174) when, and only when,
	description		they appear in all capitals, as shown here.
	"Mask length range lower bound. It MUST NOT be less than
	the prefix length defined in ip-prefix.";
	}
	leaf mask-length-upper {
	type uint8 {
	range "1..128";
	}
	must "../mask-length-upper >= ../mask-length-lower" {
	error-message "The upper bound MUST NOT be less"
	+ "than lower bound.";
	}
	description
	"Mask length range upper bound. It MUST NOT be less than
	lower bound.";
	}
	}
	grouping match-set-options-group {		Copyright (c) 2021 IETF Trust and the persons identified as
	description		authors of the code. All rights reserved.
	"Grouping containing options relating to how a particular set
	will be matched.";
	leaf match-set-options {		Redistribution and use in source and binary forms, with or
	type match-set-options-type;		without modification, is permitted pursuant to, and subject to
	description		the license terms contained in, the Simplified BSD License set
	"Optional parameter that governs the behavior of the		forth in Section 4.c of the IETF Trust's Legal Provisions
	match operation.";		Relating to IETF Documents
	}		(https://trustee.ietf.org/license-info).
	}
	grouping match-set-options-restricted-group {		This version of this YANG module is part of RFC 9067;
	description		see the RFC itself for full legal notices.";
	"Grouping for a restricted set of match operation
	modifiers.";
	leaf match-set-options {		reference
	type match-set-options-type {		"RFC 9067: A YANG Data Model for Routing Policy.";
	enum any {
	description
	"Match is true if given value matches any
	member of the defined set.";
	}
	enum invert {
	description
	"Match is true if given value does not match
	any member of the defined set.";
	}
	}
	description
	"Optional parameter that governs the behavior of the
	match operation. This leaf only supports matching on
	'any' member of the set or 'invert' the match.
	Matching on 'all' is not supported.";
	}
	}
	grouping apply-policy-group {		revision 2021-09-28 {
	description		description
	"Top level container for routing policy applications. This		"Initial revision.";
	grouping is intended to be used in routing models where		reference
	needed.";		"RFC 9067: A YANG Data Model for Routing Policy.";
			}
	container apply-policy {		/* Identities */
	description
	"Anchor point for routing policies in the model.
	Import and export policies are with respect to the local
	routing table, i.e., export (send) and import (receive),
	depending on the context.";
	leaf-list import-policy {		identity metric-type {
	type leafref {		description
	path "/rt-pol:routing-policy/rt-pol:policy-definitions/" +		"Base identity for route metric types.";
	"rt-pol:policy-definition/rt-pol:name";		}
	require-instance true;
	}
	ordered-by user;
	description
	"List of policy names in sequence to be applied on
	receiving redistributed routes from another routing protocol
	or receiving a routing update in the current context, e.g.,
	for the current peer group, neighbor, address family, etc.";
	}
	leaf default-import-policy {		identity ospf-type-1-metric {
	type default-policy-type;		base metric-type;
	default reject-route;		description
	description		"Identity for the OSPF type 1 external metric types. It
	"Explicitly set a default policy if no policy definition		is only applicable to OSPF routes.";
	in the import policy chain is satisfied.";		reference
	}		"RFC 2328: OSPF Version 2";
			}
	leaf-list export-policy {		identity ospf-type-2-metric {
	type leafref {		base metric-type;
	path "/rt-pol:routing-policy/rt-pol:policy-definitions/" +		description
	"rt-pol:policy-definition/rt-pol:name";		"Identity for the OSPF type 2 external metric types. It
	require-instance true;		is only applicable to OSPF routes.";
	}		reference
	ordered-by user;		"RFC 2328: OSPF Version 2";
	description		}
	"List of policy names in sequence to be applied on
	redistributing routes from one routing protocol to another
	or sending a routing update in the current context, e.g.,
	for the current peer group, neighbor, address family, etc.";
	}
	leaf default-export-policy {		identity isis-internal-metric {
	type default-policy-type;		base metric-type;
	default reject-route;		description
	description		"Identity for the IS-IS internal metric types. It is only
	"Explicitly set a default policy if no policy definition		applicable to IS-IS routes.";
	in the export policy chain is satisfied.";		reference
	}		"RFC 5302: Domain-Wide Prefix Distribution with
	}		Two-Level IS-IS";
	}		}
	container routing-policy {		identity isis-external-metric {
	description		base metric-type;
	"Top-level container for all routing policy.";		description
			"Identity for the IS-IS external metric types. It is only
			applicable to IS-IS routes.";
			reference
			"RFC 5302: Domain-Wide Prefix Distribution with
			Two-Level IS-IS";
			}
	container defined-sets {		identity route-level {
	description		description
	"Predefined sets of attributes used in policy match		"Base identity for route import level.";
	statements.";		}
	container prefix-sets {		identity ospf-normal {
	description		base route-level;
	"Data definitions for a list of IPv4 or IPv6		description
	prefixes which are matched as part of a policy.";		"Identity for OSPF importation into normal areas.
	list prefix-set {		It is only applicable to routes imported
	key "name mode";		into the OSPF protocol.";
	description		reference
	"List of the defined prefix sets";		"RFC 2328: OSPF Version 2";
			}
	leaf name {		identity ospf-nssa-only {
	type string;		base route-level;
	description		description
	"Name of the prefix set -- this is used as a label to		"Identity for the OSPF Not-So-Stubby Area (NSSA) area
	reference the set in match conditions.";		importation. It is only applicable to routes imported
	}		into the OSPF protocol.";
			reference
			"RFC 3101: The OSPF Not-So-Stubby Area (NSSA) Option";
			}
	leaf mode {		identity ospf-normal-nssa {
	type enumeration {		base route-level;
	enum ipv4 {		description
	description		"Identity for OSPF importation into both normal and NSSA
	"Prefix set contains IPv4 prefixes only.";		areas. It is only applicable to routes imported into
	}		the OSPF protocol.";
	enum ipv6 {		reference
	description		"RFC 3101: The OSPF Not-So-Stubby Area (NSSA) Option";
	"Prefix set contains IPv6 prefixes only.";		}
	}
	}
	description
	"Indicates the mode of the prefix set, in terms of
	which address families (IPv4 or IPv6) are present.
	The mode provides a hint, all prefixes MUST be of
	the indicated type. The device MUST validate that
	all prefixes and reject the configuration if there
	is a discrepancy.";
	}
	container prefixes {		identity isis-level-1 {
	description		base route-level;
	"Container for the list of prefixes in a policy		description
	prefix list. Since individual prefixes do not have		"Identity for IS-IS Level 1 area importation. It is only
	unique actions, the order in which the prefix in		applicable to routes imported into the IS-IS protocol.";
	prefix-list are matched has no impact on the outcome		reference
	and is left to the implementation. A given prefix-set		"RFC 5302: Domain-Wide Prefix Distribution with
	condition is satisfied if the input prefix matches		Two-Level IS-IS";
	any of the prefixes in the prefix-set.";		}
	list prefix-list {		identity isis-level-2 {
	key "ip-prefix mask-length-lower mask-length-upper";		base route-level;
	description		description
	"List of prefixes in the prefix set.";		"Identity for IS-IS Level 2 area importation. It is only
			applicable to routes imported into the IS-IS protocol.";
			reference
			"RFC 5302: Domain-Wide Prefix Distribution with
			Two-Level IS-IS";
			}
	uses prefix;		identity isis-level-1-2 {
	}		base route-level;
	}		description
	}		"Identity for IS-IS importation into both Level 1 and Level 2
	}		areas. It is only applicable to routes imported into the
	container neighbor-sets {		IS-IS protocol.";
	description		reference
	"Data definition for a list of IPv4 or IPv6		"RFC 5302: Domain-Wide Prefix Distribution with
	neighbors which can be matched in a routing policy.";		Two-Level IS-IS";
			}
	list neighbor-set {		identity proto-route-type {
	key "name";		description
	description		"Base identity for route type within a protocol.";
	"List of defined neighbor sets for use in policies.";		}
	leaf name {		identity isis-level-1-type {
	type string;		base proto-route-type;
	description		description
	"Name of the neighbor set -- this is used as a label		"Identity for IS-IS Level 1 route type. It is only
	to reference the set in match conditions.";		applicable to IS-IS routes.";
	}		reference
			"RFC 5302: Domain-Wide Prefix Distribution with
			Two-Level IS-IS";
			}
	leaf-list address {		identity isis-level-2-type {
	type inet:ip-address;		base proto-route-type;
	description		description
	"List of IP addresses in the neighbor set.";		"Identity for IS-IS Level 2 route type. It is only
	}		applicable to IS-IS routes.";
	}		reference
	}		"RFC 5302: Domain-Wide Prefix Distribution with
			Two-Level IS-IS";
			}
	container tag-sets {		identity ospf-internal-type {
	description		base proto-route-type;
	"Data definitions for a list of tags which can		description
	be matched in policies.";		"Identity for OSPF intra-area or inter-area route type.
			It is only applicable to OSPF routes.";
			reference
			"RFC 2328: OSPF Version 2";
			}
	list tag-set {		identity ospf-external-type {
	key "name";		base proto-route-type;
	description		description
	"List of tag set definitions.";		"Identity for OSPF external type 1/2 route type.
			It is only applicable to OSPF routes.";
			reference
			"RFC 2328: OSPF Version 2";
			}
	leaf name {		identity ospf-external-t1-type {
	type string;		base ospf-external-type;
	description		description
	"Name of the tag set -- this is used as a label to		"Identity for OSPF external type 1 route type.
	reference the set in match conditions.";		It is only applicable to OSPF routes.";
	}		reference
			"RFC 2328: OSPF Version 2";
			}
	leaf-list tag-value {		identity ospf-external-t2-type {
	type tag-type;		base ospf-external-type;
	description		description
	"Value of the tag set member.";		"Identity for OSPF external type 2 route type.
	}		It is only applicable to OSPF routes.";
	}		reference
			"RFC 2328: OSPF Version 2";
			}
	}		identity ospf-nssa-type {
	}		base proto-route-type;
			description
			"Identity for OSPF NSSA type 1/2 route type.
			It is only applicable to OSPF routes.";
			reference
			"RFC 3101: The OSPF Not-So-Stubby Area (NSSA) Option";
			}
	container policy-definitions {		identity ospf-nssa-t1-type {
	description		base ospf-nssa-type;
	"Enclosing container for the list of top-level policy		description
	definitions.";		"Identity for OSPF NSSA type 1 route type.
			It is only applicable to OSPF routes.";
			reference
			"RFC 3101: The OSPF Not-So-Stubby Area (NSSA) Option";
			}
	leaf match-modified-attributes {		identity ospf-nssa-t2-type {
	type boolean;		base ospf-nssa-type;
	config false;		description
	description		"Identity for OSPF NSSA type 2 route type.
	"This boolean value dictates whether matches are performed		It is only applicable to OSPF routes.";
	on the actual route attributes or route attributes		reference
	modified by policy statements preceding the match.";		"RFC 3101: The OSPF Not-So-Stubby Area (NSSA) Option";
	}		}
	list policy-definition {		identity bgp-internal {
	key "name";		base proto-route-type;
	description		description
	"List of top-level policy definitions, keyed by unique		"Identity for routes learned from internal BGP (IBGP).
	name. These policy definitions are expected to be		It is only applicable to BGP routes.";
	referenced (by name) in policy chains specified in		reference
	import or export configuration statements.";		"RFC 4271: A Border Gateway Protocol 4 (BGP-4)";
			}
	leaf name {		identity bgp-external {
	type string;		base proto-route-type;
	description		description
	"Name of the top-level policy definition -- this name		"Identity for routes learned from external BGP (EBGP).
	is used in references to the current policy.";		It is only applicable to BGP routes.";
	}		reference
			"RFC 4271: A Border Gateway Protocol 4 (BGP-4)";
			}
	container statements {		/* Type Definitions */
	description
	"Enclosing container for policy statements.";
	list statement {		typedef default-policy-type {
	key "name";		type enumeration {
	ordered-by user;		enum accept-route {
	description		description
	"Policy statements group conditions and actions		"Default policy to accept the route.";
	within a policy definition. They are evaluated in		}
	the order specified.";		enum reject-route {
			description
			"Default policy to reject the route.";
			}
			}
			description
			"Type used to specify route disposition in
			a policy chain. This typedef is used in
			the default import and export policy.";
			}
	leaf name {		typedef policy-result-type {
	type string;		type enumeration {
	description		enum accept-route {
	"Name of the policy statement.";		description
			"Policy accepts the route.";
			}
			enum reject-route {
			description
			"Policy rejects the route.";
			}
			}
			description
			"Type used to specify route disposition in
			a policy chain.";
			}
	}		typedef tag-type {
			type union {
			type uint32;
			type yang:hex-string;
			}
			description
			"Type for expressing route tags on a local system,
			including IS-IS and OSPF; may be expressed as either decimal
			or hexadecimal integer.";
			reference
			"RFC 2328: OSPF Version 2
			RFC 5130: A Policy Control Mechanism in IS-IS Using
			Administrative Tags";
			}
	container conditions {		typedef match-set-options-type {
	description		type enumeration {
	"Condition statements for the current policy		enum any {
	statement.";		description
			"Match is true if given value matches any member
			of the defined set.";
			}
			enum all {
			description
			"Match is true if given value matches all
			members of the defined set.";
			}
			enum invert {
			description
			"Match is true if given value does not match any
			member of the defined set.";
			}
			}
			default "any";
			description
			"Options that govern the behavior of a match statement. The
			default behavior is any, i.e., the given value matches any
			of the members of the defined set.";
			}
	leaf call-policy {		typedef metric-modification-type {
	type leafref {		type enumeration {
	path "../../../../../../" +		enum set-metric {
	"rt-pol:policy-definitions/" +		description
	"rt-pol:policy-definition/rt-pol:name";		"Set the metric to the specified value.";
	require-instance true;		}
	}		enum add-metric {
	description		description
	"Applies the statements from the specified policy		"Add the specified value to the existing metric.
	definition and then returns control to the current		If the result overflows the maximum metric
	policy statement. Note that the called policy		(0xffffffff), set the metric to the maximum.";
	may itself call other policies (subject to		}
	implementation limitations). This is intended to		enum subtract-metric {
	provide a policy 'subroutine' capability. The		description
	called policy SHOULD contain an explicit or a		"Subtract the specified value from the existing metric. If
	default route disposition that returns an		the result is less than 0, set the metric to 0.";
	effective true (accept-route) or false		}
	(reject-route), otherwise the behavior may be		}
	ambiguous.";		description
	}		"Type used to specify how to set the metric given the
			specified value.";
			}
	leaf source-protocol {		/* Groupings */
	type identityref {
	base rt:control-plane-protocol;
	}
	description
	"Condition to check the protocol / method used to
	install the route into the local routing table.";
	}
	container match-interface {		grouping prefix {
	leaf interface {		description
	type leafref {		"Configuration data for a prefix definition.
	path "/if:interfaces/if:interface/if:name";
	}
	description
	"Reference to a base interface.";
	}
	description
	"Container for interface match conditions";
	}
	container match-prefix-set {
	leaf prefix-set {
	type leafref {
	path "../../../../../../../defined-sets/" +
	"prefix-sets/prefix-set/name";
	}
	description
	"References a defined prefix set.";
	}
	uses match-set-options-restricted-group;
	description		The combination of mask-length-lower and mask-length-upper
	"Match a referenced prefix-set according to the		define a range for the mask length or single 'exact'
	logic defined in the match-set-options leaf.";		length if mask-length-lower and mask-length-upper are
	}		equal.
	container match-neighbor-set {		Example: 192.0.2.0/24 through 192.0.2.0/26 would be
	leaf neighbor-set {		expressed as prefix: 192.0.2.0/24,
	type leafref {		mask-length-lower=24,
	path "../../../../../../../defined-sets/" +		mask-length-upper=26
	"neighbor-sets/neighbor-set/name";
	require-instance true;
	}
	description
	"References a defined neighbor set.";
	}
	description		Example: 192.0.2.0/24 (an exact match) would be
	"Match a referenced neighbor set.";		expressed as prefix: 192.0.2.0/24,
	}		mask-length-lower=24,
			mask-length-upper=24
	container match-tag-set {		Example: 2001:DB8::/32 through 2001:DB8::/64 would be
	leaf tag-set {		expressed as prefix: 2001:DB8::/32,
	type leafref {		mask-length-lower=32,
	path "../../../../../../../defined-sets/" +		mask-length-upper=64";
	"tag-sets/tag-set/name";		leaf ip-prefix {
	require-instance true;		type inet:ip-prefix;
	}		mandatory true;
	description		description
	"References a defined tag set.";		"The IP prefix represented as an IPv6 or IPv4 network
	}		number followed by a prefix length with an intervening
	uses match-set-options-group;		slash character as a delimiter. All members of the
			prefix-set MUST be of the same address family as the
			prefix-set mode.";
			}
			leaf mask-length-lower {
			type uint8 {
			range "0..128";
			}
			description
			"Mask length range lower bound. It MUST NOT be less than
			the prefix length defined in ip-prefix.";
			}
			leaf mask-length-upper {
			type uint8 {
			range "1..128";
			}
			must '../mask-length-upper >= ../mask-length-lower' {
			error-message "The upper bound MUST NOT be less "
			+ "than lower bound.";
			}
			description
			"Mask length range upper bound. It MUST NOT be less than
			lower bound.";
			}
			}
	description		grouping match-set-options-group {
	"Match a referenced tag set according to the logic		description
	defined in the match-set-options leaf.";		"Grouping containing options relating to how a particular set
	}		will be matched.";
	container match-route-type {		leaf match-set-options {
	description		type match-set-options-type;
	"This container provides route-type match condition";		description
			"Optional parameter that governs the behavior of the
			match operation.";
			}
			}
	leaf-list route-type {		grouping match-set-options-restricted-group {
	type identityref {		description
	base proto-route-type;		"Grouping for a restricted set of match operation
	}		modifiers.";
	description		leaf match-set-options {
	"Condition to check the protocol-specific type		type match-set-options-type {
	of route. This is normally used during route		enum any {
	importation to select routes or to set protocol		description
	specific attributes based on the route type.";		"Match is true if given value matches any
	}		member of the defined set.";
	}		}
	}		enum invert {
			description
			"Match is true if given value does not match
			any member of the defined set.";
			}
			}
			description
			"Optional parameter that governs the behavior of the
			match operation. This leaf only supports
			the 'any' and 'invert' match options.
			Matching on 'all' is not supported.";
			}
			}
	container actions {		grouping apply-policy-group {
	description		description
	"Top-level container for policy action		"Top-level container for routing policy applications. This
	statements.";		grouping is intended to be used in routing models where
	leaf policy-result {		needed.";
	type policy-result-type;		container apply-policy {
	default reject-route;		description
	description		"Anchor point for routing policies in the model.
	"Select the final disposition for the route,		Import and export policies are with respect to the local
	either accept or reject.";		routing table, i.e., export (send) and import (receive),
	}		depending on the context.";
	container set-metric {		leaf-list import-policy {
	leaf metric-modification {		type leafref {
	type metric-modification-type;		path "/rt-pol:routing-policy/rt-pol:policy-definitions/"
	description		+ "rt-pol:policy-definition/rt-pol:name";
	"Indicates how to modify the metric.";		require-instance true;
	}		}
	leaf metric {		ordered-by user;
	type uint32;		description
	description		"List of policy names in sequence to be applied on
	"Metric value to set, add, or subtract.";		receiving redistributed routes from another routing
	}		protocol or receiving a routing update in the current
	description		context, e.g., for the current peer group, neighbor,
	"Set the metric for the route.";		address family, etc.";
	}		}
	container set-metric-type {		leaf default-import-policy {
	leaf metric-type {		type default-policy-type;
	type identityref {		default "reject-route";
	base metric-type;		description
	}		"Explicitly set a default policy if no policy definition
	description		in the import policy chain is satisfied.";
	"Route metric type.";		}
	}		leaf-list export-policy {
	description		type leafref {
	"Set the metric type for the route.";		path "/rt-pol:routing-policy/rt-pol:policy-definitions/"
	}		+ "rt-pol:policy-definition/rt-pol:name";
	container set-route-level {		require-instance true;
	leaf route-level {		}
	type identityref {		ordered-by user;
	base route-level;		description
	}		"List of policy names in sequence to be applied on
	description		redistributing routes from one routing protocol to another
	"Route import level.";		or sending a routing update in the current context, e.g.,
	}		for the current peer group, neighbor, address family,
	description		etc.";
	"Set the level for importation or		}
	exportation of routes.";		leaf default-export-policy {
	}		type default-policy-type;
	leaf set-route-preference {		default "reject-route";
	type uint16;		description
	description		"Explicitly set a default policy if no policy definition
	"Set the preference for the route. It is also		in the export policy chain is satisfied.";
	known as 'administrative distance', allows for		}
	selecting the preferred route among routes with		}
	the same destination prefix. A smaller value is		}
	more preferred.";
	}
	leaf set-tag {
	type tag-type;
	description
	"Set the tag for the route.";
	}
	leaf set-application-tag {
	type tag-type;
	description
	"Set the application tag for the route.
	The application-specific tag is an additional tag
	that can be used by applications that require
	semantics and/or policy different from that of the
	tag. For example, the tag is usually automatically
	advertised in OSPF AS-External Link State
	Advertisements (LSAs) while this application-specific
	tag is not advertised implicitly.";
	}
	}
	}
	}
	}
	}
	}		container routing-policy {
	}		description
	<CODE ENDS>		"Top-level container for all routing policy.";
			container defined-sets {
			description
			"Predefined sets of attributes used in policy match
			statements.";
			container prefix-sets {
			description
			"Data definitions for a list of IPv4 or IPv6
			prefixes that are matched as part of a policy.";
			list prefix-set {
			key "name mode";
			description
			"List of the defined prefix sets";
			leaf name {
			type string;
			description
			"Name of the prefix set; this is used as a label to
			reference the set in match conditions.";
			}
			leaf mode {
			type enumeration {
			enum ipv4 {
			description
			"Prefix set contains IPv4 prefixes only.";
			}
			enum ipv6 {
			description
			"Prefix set contains IPv6 prefixes only.";
			}
			}
			description
			"Indicates the mode of the prefix set in terms of
			which address families (IPv4 or IPv6) are present.
			The mode provides a hint; all prefixes MUST be of
			the indicated type. The device MUST validate
			all prefixes and reject the configuration if there
			is a discrepancy.";
			}
			container prefixes {
			description
			"Container for the list of prefixes in a policy
			prefix list. Since individual prefixes do not have
			unique actions, the order in which the prefix in
			prefix-list are matched has no impact on the outcome
			and is left to the implementation. A given prefix-set
			condition is satisfied if the input prefix matches
			any of the prefixes in the prefix-set.";
			list prefix-list {
			key "ip-prefix mask-length-lower mask-length-upper";
			description
			"List of prefixes in the prefix set.";
			uses prefix;
			}
			}
			}
			}
			container neighbor-sets {
			description
			"Data definition for a list of IPv4 or IPv6
			neighbors that can be matched in a routing policy.";
			list neighbor-set {
			key "name";
			description
			"List of defined neighbor sets for use in policies.";
			leaf name {
			type string;
			description
			"Name of the neighbor set; this is used as a label
			to reference the set in match conditions.";
			}
			leaf-list address {
			type inet:ip-address;
			description
			"List of IP addresses in the neighbor set.";
			}
			}
			}
			container tag-sets {
			description
			"Data definitions for a list of tags that can
			be matched in policies.";
			list tag-set {
			key "name";
			description
			"List of tag set definitions.";
			leaf name {
			type string;
			description
			"Name of the tag set; this is used as a label to
			reference the set in match conditions.";
			}
			leaf-list tag-value {
			type tag-type;
			description
			"Value of the tag set member.";
			}
			}
			}
			}
			container policy-definitions {
			description
			"Enclosing container for the list of top-level policy
			definitions.";
			leaf match-modified-attributes {
			type boolean;
			config false;
			description
			"This boolean value dictates whether matches are performed
			on the actual route attributes or route attributes
			modified by policy statements preceding the match.";
			}
			list policy-definition {
			key "name";
			description
			"List of top-level policy definitions, keyed by unique
			name. These policy definitions are expected to be
			referenced (by name) in policy chains specified in
			import or export configuration statements.";
			leaf name {
			type string;
			description
			"Name of the top-level policy definition; this name
			is used in references to the current policy.";
			}
			container statements {
			description
			"Enclosing container for policy statements.";
			list statement {
			key "name";
			ordered-by user;
			description
			"Policy statements group conditions and actions
			within a policy definition. They are evaluated in
			the order specified.";
			leaf name {
			type string;
			description
			"Name of the policy statement.";
			}
			container conditions {
			description
			"Condition statements for the current policy
			statement.";
			leaf call-policy {
			type leafref {
			path "../../../../../../"
			+ "rt-pol:policy-definitions/"
			+ "rt-pol:policy-definition/rt-pol:name";
			require-instance true;
			}
			description
			"Applies the statements from the specified policy
			definition and then returns control to the current
			policy statement. Note that the called policy
			may itself call other policies (subject to
			implementation limitations). This is intended to
			provide a policy 'subroutine' capability. The
			called policy SHOULD contain an explicit or a
			default route disposition that returns an
			effective true (accept-route) or false
			(reject-route); otherwise, the behavior may be
			ambiguous. The call-policy MUST NOT have been
			previously called without returning (i.e.,
			recursion is not allowed).";
			}
			leaf source-protocol {
			type identityref {
			base rt:control-plane-protocol;
			}
			description
			"Condition to check the protocol / method used to
			install the route into the local routing table.";
			}
			container match-interface {
			leaf interface {
			type if:interface-ref;
			description
			"Reference to a base interface.";
			}
			description
			"Container for interface match conditions";
			}
			container match-prefix-set {
			leaf prefix-set {
			type leafref {
			path "../../../../../../../defined-sets/"
			+ "prefix-sets/prefix-set/name";
			}
			description
			"References a defined prefix set.";
			}
			uses match-set-options-restricted-group;
			description
			"Match a referenced prefix-set according to the
			logic defined in the match-set-options leaf.";
			}
			container match-neighbor-set {
			leaf neighbor-set {
			type leafref {
			path "../../../../../../../defined-sets/"
			+ "neighbor-sets/neighbor-set/name";
			require-instance true;
			}
			description
			"References a defined neighbor set.";
			}
			description
			"Match a referenced neighbor set.";
			}
			container match-tag-set {
			leaf tag-set {
			type leafref {
			path "../../../../../../../defined-sets/"
			+ "tag-sets/tag-set/name";
			require-instance true;
			}
			description
			"References a defined tag set.";
			}
			uses match-set-options-group;
			description
			"Match a referenced tag set according to the logic
			defined in the match-set-options leaf.";
			}
			container match-route-type {
			description
			"This container provides route-type match
			condition";
			leaf-list route-type {
			type identityref {
			base proto-route-type;
			}
			description
			"Condition to check the protocol-specific type
			of route. This is normally used during route
			importation to select routes or to set
			protocol-specific attributes based on the route
			type.";
			}
			}
			}
			container actions {
			description
			"Top-level container for policy action
			statements.";
			leaf policy-result {
			type policy-result-type;
			description
			"Select the final disposition for the route,
			either accept or reject.";
			}
			container set-metric {
			leaf metric-modification {
			type metric-modification-type;
			description
			"Indicates how to modify the metric.";
			}
			leaf metric {
			type uint32;
			description
			"Metric value to set, add, or subtract.";
			}
			description
			"Set the metric for the route.";
			}
			container set-metric-type {
			leaf metric-type {
			type identityref {
			base metric-type;
			}
			description
			"Route metric type.";
			}
			description
			"Set the metric type for the route.";
			}
			container set-route-level {
			leaf route-level {
			type identityref {
			base route-level;
			}
			description
			"Route import level.";
			}
			description
			"Set the level for importation or
			exportation of routes.";
			}
			leaf set-route-preference {
			type uint16;
			description
			"Set the preference for the route. It is also
			known as 'administrative distance' and allows for
			selecting the preferred route among routes with
			the same destination prefix. A smaller value is
			more preferred.";
			}
			leaf set-tag {
			type tag-type;
			description
			"Set the tag for the route.";
			}
			leaf set-application-tag {
			type tag-type;
			description
			"Set the application tag for the route.
			The application-specific tag is an additional tag
			that can be used by applications that require
			semantics and/or policy different from that of the
			tag. For example, the tag is usually
			automatically advertised in OSPF AS-External Link
			State Advertisements (LSAs) while this
			application-specific tag is not advertised
			implicitly.";
			}
			}
			}
			}
			}
			}
			}
			}
			<CODE ENDS>
	8. Security Considerations		8. Security Considerations
	The YANG module specified in this document defines 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 Network Configuration Access Control Model (NACM) [RFC8341]
	to restrict access for particular NETCONF or RESTCONF users to a pre-		provides the means to restrict access for particular NETCONF or
	configured subset of all available NETCONF or RESTCONF protocol		RESTCONF users to a preconfigured subset of all available NETCONF or
	operations and content.		RESTCONF protocol operations and content.
	There are a number of data nodes defined in this YANG module that are		There are a number of data nodes defined in this YANG module that are
	writable/creatable/deletable (i.e., config true, which is the		writable/creatable/deletable (i.e., config true, which is the
	default). These data nodes may be considered sensitive or vulnerable		default). These data nodes may be considered sensitive or vulnerable
	in some network environments. Write operations (e.g., edit-config)		in some network environments. Write operations (e.g., edit-config)
	to these data nodes without proper protection can have a negative		to these data nodes without proper protection can have a negative
	effect on network operations. These are the subtrees and data nodes		effect on network operations. These are the subtrees and data nodes
	and their sensitivity/vulnerability:		and their sensitivity/vulnerability:
	/routing-policy/defined-sets/prefix-sets -- Modification to		/routing-policy/defined-sets/prefix-sets
	prefix-sets could result in a Denial-of-Service (DoS) attack. An		Modification to prefix sets could result in a Denial-of-Service
	attacker may try to modify prefix-sets and redirect or drop		(DoS) attack. An attacker may try to modify prefix sets and
	traffic. Redirection of traffic could be used as part of a more		redirect or drop traffic. Redirection of traffic could be used as
	elaborate attack to either collect sensitive information or		part of a more elaborate attack to either collect sensitive
	masquerade a service. Additionally, a control-plane DoS attack		information or masquerade a service. Additionally, a control
	could be accomplished by allowing a large number of routes to be		plane DoS attack could be accomplished by allowing a large number
	leaked into a routing protocol domain (e.g., BGP).		of routes to be leaked into a routing protocol domain (e.g., BGP).
	/routing-policy/defined-sets/neighbor-sets -- Modification to the		/routing-policy/defined-sets/neighbor-sets
	neighbor-sets could be used to mount a DoS attack or more		Modification to the neighbor sets could be used to mount a DoS
	elaborate attack as with prefix-sets. For example, a DoS attack		attack or more elaborate attack as with prefix sets. For example,
	could be mounted by changing the neighbor-set from which routes		a DoS attack could be mounted by changing the neighbor set from
	are accepted.		which routes are accepted.
	/routing-policy/defined-sets/tag-sets -- Modification to the tag-		/routing-policy/defined-sets/tag-sets
	sets could be used to mount a DoS attack. Routes with certain		Modification to the tag sets could be used to mount a DoS attack.
	tags might be redirected or dropped. The implications are similar		Routes with certain tags might be redirected or dropped. The
	to prefix-sets and neighbor-sets. However, the attack may be more		implications are similar to prefix sets and neighbor sets.
	difficult to detect as the routing policy usage of route tags and		However, the attack may be more difficult to detect as the routing
	intent must be understood to recognize the breach. Conversely,		policy usage of route tags and intent must be understood to
	the implications of prefix-set or neighbor set modification are		recognize the breach. Conversely, the implications of prefix set
	easier to recognize.		or neighbor set modification are easier to recognize.
	/routing-policy/policy-definitions/policy-definition		/routing-policy/policy-definitions/policy-
	/statements/statement/conditions -- Modification to the conditions		definition/statements/statement/conditions
	could be used to mount a DoS attack or other attack. An attacker		Modification to the conditions could be used to mount a DoS attack
	may change a policy condition and redirect or drop traffic. As		or other attack. An attacker may change a policy condition and
	with prefix-sets, neighbor-sets, or tag-sets, traffic redirection		redirect or drop traffic. As with prefix sets, neighbor sets, or
	could be used as part of a more elaborate attack.		tag sets, traffic redirection could be used as part of a more
			elaborate attack.
	/routing-policy/policy-definitions/policy-definition		/routing-policy/policy-definitions/policy-
	/statements/statement/actions -- Modification to actions could be		definition/statements/statement/actions
	used to mount a DoS attack or other attack. Traffic may be		Modification to actions could be used to mount a DoS attack or
	redirected or dropped. As with prefix-sets, neighbor-sets, or		other attack. Traffic may be redirected or dropped. As with
	tag-sets, traffic redirection could be used as part of a more		prefix sets, neighbor sets, or tag sets, traffic redirection could
	elaborate attack. Additionally, route attributes may be changed		be used as part of a more elaborate attack. Additionally, route
	to mount a second-level attack that is more difficult to detect.		attributes may be changed to mount a second-level attack that is
			more difficult to detect.
	Some of the readable data nodes in the YANG module may be considered		Some of the readable data nodes in the YANG module may be considered
	sensitive or vulnerable in some network environments. It is thus		sensitive or vulnerable in some network environments. It is thus
	important to control read access (e.g., via get, get-config, or		important to control read access (e.g., via get, get-config, or
	notification) to these data nodes. These are the subtrees and data		notification) to these data nodes. These are the subtrees and data
	nodes and their sensitivity/vulnerability:		nodes and their sensitivity/vulnerability:
	/routing-policy/defined-sets/prefix-sets -- Knowledge of these		/routing-policy/defined-sets/prefix-sets
	data nodes can be used to ascertain which local prefixes are		Knowledge of these data nodes can be used to ascertain which local
	susceptible to a Denial-of-Service (DoS) attack.		prefixes are susceptible to a DoS attack.
	/routing-policy/defined-sets/prefix-sets -- Knowledge of these		/routing-policy/defined-sets/neighbor-sets
	data nodes can be used to ascertain local neighbors against whom		Knowledge of these data nodes can be used to ascertain local
	to mount a Denial-of-Service (DoS) attack.		neighbors against whom to mount a DoS attack.
	/routing-policy/policy-definitions/policy-definition /statements/		/routing-policy/policy-definitions/policy-definition/statements/
	-- Knowledge of these data nodes can be used to attack the local		Knowledge of these data nodes can be used to attack the local
	router with a Denial-of-Service (DoS) attack. Additionally,		router with a DoS attack. Additionally, policies and their
	policies and their attendant conditions and actions should be		attendant conditions and actions should be considered proprietary
	considered proprietary and disclosure could be used to ascertain		and disclosure could be used to ascertain partners, customers, and
	partners, customers, and supplies. Furthermore, the policies		suppliers. Furthermore, the policies themselves could represent
	themselves could represent intellectual property and disclosure		intellectual property and disclosure could diminish their
	could diminish their corresponding business advantage.		corresponding business advantage.
	Routing policy configuration has a significant impact on network		Routing policy configuration has a significant impact on network
	operations, and, as such, other YANG models that reference routing		operations, and as such, other YANG data models that reference
	policies are also susceptible to vulnerabilities relating the YANG		routing policies are also susceptible to vulnerabilities relating to
	data nodes specified above.		the YANG data nodes specified above.
	9. IANA Considerations		9. IANA Considerations
	This document registers a URI in the IETF XML registry [RFC3688].		IANA has registered the following URI in the "ns" subregistry of the
	Following the format in [RFC3688], the following registration is		"IETF XML Registry" [RFC3688]:
	requested to be made:
	URI: urn:ietf:params:xml:ns:yang:ietf-routing-policy
	Registrant Contact: The IESG.
	XML: N/A, the requested URI is an XML namespace.
	This document registers a YANG module in the YANG Module Names
	registry [RFC6020].
	name: ietf-routing-policy
	namespace: urn:ietf:params:xml:ns:yang:ietf-routing-policy
	prefix: rt-pol
	reference: RFC XXXX
	10. Acknowledgements
	The routing policy module defined in this document is based on the		URI: urn:ietf:params:xml:ns:yang:ietf-routing-policy
	OpenConfig route policy model. The authors would like to thank to		Registrant Contact: The IESG
	OpenConfig for their contributions, especially Anees Shaikh, Rob		XML: N/A; the requested URI is an XML namespace.
	Shakir, Kevin D'Souza, and Chris Chase.
	The authors are grateful for valuable contributions to this document		IANA has registered the following YANG module in the "YANG Module
	and the associated models from: Ebben Aires, Luyuan Fang, Josh		Names" subregistry [RFC6020] within the "YANG Parameters" registry:
	George, Stephane Litkowski, Ina Minei, Carl Moberg, Eric Osborne,
	Steve Padgett, Juergen Schoenwaelder, Jim Uttaro, Russ White, and
	John Heasley.
	Thanks to Mahesh Jethanandani, John Scudder, Chris Bowers and Tom		Name: ietf-routing-policy
	Petch for their reviews and comments.		Maintained by IANA? N
			Namespace: urn:ietf:params:xml:ns:yang:ietf-routing-policy
			Prefix: rt-pol
			Reference: RFC 9067
	11. References		10. References
	11.1. Normative references		10.1. Normative References
	[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 36 ¶		skipping to change at line 1634 ¶
	[RFC8349] Lhotka, L., Lindem, A., and Y. Qu, "A YANG Data Model for		[RFC8349] Lhotka, L., Lindem, A., and Y. Qu, "A YANG Data Model for
	Routing Management (NMDA Version)", RFC 8349,		Routing Management (NMDA Version)", RFC 8349,
	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>.
	11.2. Informative references		10.2. Informative References
	[I-D.ietf-idr-bgp-model]		[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", Work in
	bgp-model-11 (work in progress), July 2021.		Progress, Internet-Draft, draft-ietf-idr-bgp-model-09, 28
			June 2020, <https://datatracker.ietf.org/doc/html/draft-
			ietf-idr-bgp-model-09>.
	Appendix A. Routing protocol-specific policies		[W3C.REC-xml11]
			Bray, T., Paoli, J., Sperberg-McQueen, M., Maler, E.,
			Yergeau, F., and J. Cowan, "Extensible Markup Language
			(XML) 1.1 (Second Edition)", W3C Consortium
			Recommendation REC-xml11-20060816, 16 August 2006,
			<https://www.w3.org/TR/2006/REC-xml11-20060816>.
			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 illustrates how another data model can augment
	can augment parts of this routing policy data model. It uses		parts of this routing policy data model. It uses specific examples
	specific examples from draft-ietf-idr-bgp-model-09 to show in a		from draft-ietf-idr-bgp-model-09 to show in a concrete manner how the
	concrete manner how the different pieces fit together. This example		different pieces fit together. This example is not normative with
	is not normative with respect to [I-D.ietf-idr-bgp-model]. The model		respect to [IDR-BGP-MODEL]. The model similarly augments BGP-
	similarly augments BGP-specific conditions and actions in the		specific conditions and actions in the corresponding sections of the
	corresponding sections of the routing policy model. In the example		routing policy model. In the example below, the XPath prefix "bp:"
	below, the XPath prefix "bp:" specifies import from the ietf-bgp-		specifies import from the ietf-bgp-policy sub-module and the XPath
	policy sub-module and the XPath prefix "bt:" specifies import from		prefix "bt:" specifies import from the ietf-bgp-types sub-module
	the ietf-bgp-types sub-module [I-D.ietf-idr-bgp-model].		[IDR-BGP-MODEL].
	module: ietf-routing-policy		module: ietf-routing-policy
	+--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
	| | +--rw prefix-list* [ip-prefix mask-length-lower		| | +--rw prefix-list* [ip-prefix mask-length-lower
	| | mask-length-upper]		| | mask-length-upper]
	| | +--rw ip-prefix inet:ip-prefix		| | +--rw ip-prefix inet:ip-prefix
	| | +--rw mask-length-lower uint8		| | +--rw mask-length-lower uint8
	| | +--rw mask-length-upper uint8		| | +--rw mask-length-upper uint8
	| +--rw neighbor-sets		| +--rw neighbor-sets
	| | +--rw neighbor-set* [name]		| | +--rw neighbor-set* [name]
	| | +--rw name string		| | +--rw name string
	| | +--rw address* inet:ip-address		| | +--rw address* inet:ip-address
	| +--rw tag-sets		| +--rw tag-sets
	| | +--rw tag-set* [name]		| | +--rw tag-set* [name]
	| | +--rw name string		| | +--rw name string
	| | +--rw tag-value* tag-type		| | +--rw tag-value* tag-type
	| +--rw bp:bgp-defined-sets		| +--rw bp:bgp-defined-sets
	| +--rw bp:community-sets		| +--rw bp:community-sets
	| | +--rw bp:community-set* [name]		| | +--rw bp:community-set* [name]
	| | +--rw bp:name string		| | +--rw bp:name string
	| | +--rw bp:member* union		| | +--rw bp:member* union
	| +--rw bp:ext-community-sets		| +--rw bp:ext-community-sets
	| | +--rw bp:ext-community-set* [name]		| | +--rw bp:ext-community-set* [name]
	| | +--rw bp:name string		| | +--rw bp:name string
	| | +--rw bp:member* union		| | +--rw bp:member* union
	| +--rw bp:as-path-sets		| +--rw bp:as-path-sets
	| +--rw bp:as-path-set* [name]		| +--rw bp:as-path-set* [name]
	| +--rw bp:name string		| +--rw bp:name string
	| +--rw bp:member* string		| +--rw bp:member* string
	+--rw policy-definitions		+--rw policy-definitions
	+--ro match-modified-attributes? boolean		+--ro match-modified-attributes? boolean
	+--rw policy-definition* [name]		+--rw policy-definition* [name]
	+--rw name string		+--rw name string
	+--rw statements		+--rw statements
	+--rw statement* [name]		+--rw statement* [name]
	+--rw name string		+--rw name string
	+--rw conditions		+--rw conditions
	| +--rw call-policy?		| +--rw call-policy?
	| +--rw source-protocol? identityref		| +--rw source-protocol? identityref
	| +--rw match-interface		| +--rw match-interface
	| | +--rw interface?		| | +--rw interface? if:interface-ref
	| +--rw match-prefix-set		| +--rw match-prefix-set
	| | +--rw prefix-set? prefix-set/name		| | +--rw prefix-set? prefix-set/name
	| | +--rw match-set-options? match-set-options-type		| | +--rw match-set-options?
	| +--rw match-neighbor-set		| | match-set-options-type
	| | +--rw neighbor-set?		| +--rw match-neighbor-set
	| +--rw match-tag-set		| | +--rw neighbor-set?
	| | +--rw tag-set?		| +--rw match-tag-set
	| | +--rw match-set-options? match-set-options-type		| | +--rw tag-set?
	| +--rw match-route-type* identityref		| | +--rw match-set-options?
	| +--rw bp:bgp-conditions		| | match-set-options-type
	| +--rw bp:med-eq? uint32		| +--rw match-route-type
	| +--rw bp:origin-eq? bt:bgp-origin-attr-type		| +--rw route-type* identityref
	| +--rw bp:next-hop-in* inet:ip-address-no-zone		| +--rw bp:bgp-conditions
	| +--rw bp:afi-safi-in* identityref		| +--rw bp:med-eq? uint32
	| +--rw bp:local-pref-eq? uint32		| +--rw bp:origin-eq? bt:bgp-origin-attr-type
	| +--rw bp:route-type? enumeration		| +--rw bp:next-hop-in* inet:ip-address-no-zone
	| +--rw bp:community-count		| +--rw bp:afi-safi-in* identityref
	| +--rw bp:as-path-length		| +--rw bp:local-pref-eq? uint32
	| +--rw bp:match-community-set		| +--rw bp:route-type? enumeration
	| | +--rw bp:community-set?		| +--rw bp:community-count
	| | +--rw bp:match-set-options?		| +--rw bp:as-path-length
	| +--rw bp:match-ext-community-set		| +--rw bp:match-community-set
	| | +--rw bp:ext-community-set?		| | +--rw bp:community-set?
	| | +--rw bp:match-set-options?		| | +--rw bp:match-set-options?
	| +--rw bp:match-as-path-set		| +--rw bp:match-ext-community-set
	| +--rw bp:as-path-set?		| | +--rw bp:ext-community-set?
	| +--rw bp:match-set-options?		| | +--rw bp:match-set-options?
	+--rw actions		| +--rw bp:match-as-path-set
	+--rw policy-result? policy-result-type		| +--rw bp:as-path-set?
	+--rw set-metric		| +--rw bp:match-set-options?
	| +--rw metric-modification?		+--rw actions
	| +--rw metric? uint32		+--rw policy-result? policy-result-type
	+--rw set-metric-type		+--rw set-metric
	| +--rw metric-type? identityref		| +--rw metric-modification?
	+--rw set-route-level		| +--rw metric? uint32
	| +--rw route-level? identityref		+--rw set-metric-type
	+--rw set-route-preference? uint16		| +--rw metric-type? identityref
	+--rw set-tag? tag-type		+--rw set-route-level
	+--rw set-application-tag? tag-type		| +--rw route-level? identityref
	+--rw bp:bgp-actions		+--rw set-route-preference? uint16
	+--rw bp:set-route-origin?bt:bgp-origin-attr-type		+--rw set-tag? tag-type
	+--rw bp:set-local-pref? uint32		+--rw set-application-tag? tag-type
	+--rw bp:set-next-hop? bgp-next-hop-type		+--rw bp:bgp-actions
	+--rw bp:set-med? bgp-set-med-type		+--rw bp:set-route-origin?
	+--rw bp:set-as-path-prepend		| bt:bgp-origin-attr-type
	| +--rw bp:repeat-n? uint8		+--rw bp:set-local-pref? uint32
	+--rw bp:set-community		+--rw bp:set-next-hop? bgp-next-hop-type
	| +--rw bp:method? enumeration		+--rw bp:set-med? bgp-set-med-type
	| +--rw bp:options?		+--rw bp:set-as-path-prepend
	| +--rw bp:inline		| +--rw bp:repeat-n? uint8
	| | +--rw bp:communities* union		+--rw bp:set-community
	| +--rw bp:reference		| +--rw bp:method? enumeration
	| +--rw bp:community-set-ref?		| +--rw bp:options?
	+--rw bp:set-ext-community		| +--rw bp:inline
	+--rw bp:method? enumeration		| | +--rw bp:communities* union
	+--rw bp:options?		| +--rw bp:reference
	+--rw bp:inline		| +--rw bp:community-set-ref?
	| +--rw bp:communities* union		+--rw bp:set-ext-community
	+--rw bp:reference		+--rw bp:method? enumeration
	+--rw bp:ext-community-set-ref?		+--rw bp:options?
			+--rw bp:inline
			| +--rw bp:communities* union
			+--rw bp:reference
			+--rw bp:ext-community-set-ref?
	Appendix B. Policy examples		Appendix B. Policy Examples
	Below we show examples of XML-encoded configuration data using the		Below, we show examples of XML-encoded configuration data using the
	routing policy and BGP models to illustrate both how policies are		routing policy and BGP models to illustrate both how policies are
	defined, and how they can be applied. Note that the XML has been		defined and how they can be applied. Note that the XML
	simplified for readability.		[W3C.REC-xml11] has been simplified for readability.
	The following example shows how prefix-set and tag-set can be		The following example shows how prefix set and tag set can be
	defined. The policy condition is to match a prefix-set and a tag-		defined. The policy condition is to match a prefix set and a tag
	set, and the action is to accept routes that match the condition.		set, and the action is to accept routes that match the condition.
	<config xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">		<config xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
	<routing-policy		<routing-policy
	xmlns="urn:ietf:params:xml:ns:yang:ietf-routing-policy">		xmlns="urn:ietf:params:xml:ns:yang:ietf-routing-policy">
	<defined-sets>		<defined-sets>
	<prefix-sets>		<prefix-sets>
	<prefix-set>		<prefix-set>
	<name>prefix-set-A</name>		<name>prefix-set-A</name>
	skipping to change at page 41, line 4 ¶		skipping to change at line 1856 ¶
	</conditions>		</conditions>
	<actions>		<actions>
	<policy-result>accept-route</policy-result>		<policy-result>accept-route</policy-result>
	</actions>		</actions>
	</statement>		</statement>
	</statements>		</statements>
	</policy-definition>		</policy-definition>
	</policy-definitions>		</policy-definitions>
	</routing-policy>		</routing-policy>
	</config>		</config>
	In the following example, all routes in the RIB that have been		In the following example, all routes in the RIB that have been
	learned from OSPF advertisements corresponding to OSPF intra-area and		learned from OSPF advertisements corresponding to OSPF intra-area and
	inter-area route types should get advertised into ISIS level-2		inter-area route types should get advertised into IS-IS level 2
	advertisements.		advertisements.
	<config xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">		<config xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
	<routing-policy		<routing-policy
	xmlns="urn:ietf:params:xml:ns:yang:ietf-routing-policy">		xmlns="urn:ietf:params:xml:ns:yang:ietf-routing-policy">
	<policy-definitions>		<policy-definitions>
	<policy-definition>		<policy-definition>
	<name>export-all-OSPF-prefixes-into-ISIS-level-2</name>		<name>export-all-OSPF-prefixes-into-IS-IS-level-2</name>
	<statements>		<statements>
	<statement>		<statement>
	<name>term-0</name>		<name>term-0</name>
	<conditions>		<conditions>
	<match-route-type>ospf-internal-type</match-route-type>		<match-route-type>
			<route-type>ospf-internal-type</route-type>
			</match-route-type>
	</conditions>		</conditions>
	<actions>		<actions>
	<set-route-level>		<set-route-level>
	<route-level>isis-level-2</route-level>		<route-level>isis-level-2</route-level>
	</set-route-level>		</set-route-level>
	<policy-result>accept-route</policy-result>		<policy-result>accept-route</policy-result>
	</actions>		</actions>
	</statement>		</statement>
	</statements>		</statements>
	</policy-definition>		</policy-definition>
	</policy-definitions>		</policy-definitions>
	</routing-policy>		</routing-policy>
	</config>		</config>
			Acknowledgements
			The routing policy module defined in this document is based on the
			OpenConfig route policy model. The authors would like to thank
			OpenConfig for their contributions, especially those of Anees Shaikh,
			Rob Shakir, Kevin D'Souza, and Chris Chase.
			The authors are grateful for valuable contributions to this document
			and the associated models from Ebben Aires, Luyuan Fang, Josh George,
			Stephane Litkowski, Ina Minei, Carl Moberg, Eric Osborne, Steve
			Padgett, Juergen Schoenwaelder, Jim Uttaro, Russ White, and John
			Heasley.
			Thanks to Mahesh Jethanandani, John Scudder, Alvaro Retana, Chris
			Bowers, Tom Petch, and Kris Lambrechts for their reviews and
			comments.
	Authors' Addresses		Authors' Addresses
	Yingzhen Qu		Yingzhen Qu
	Futurewei		Futurewei
	2330 Central Expressway		2330 Central Expressway
	Santa Clara CA 95050		Santa Clara, CA 95050
	USA		United States of America
	Email: yingzhen.qu@futurewei.com		Email: yingzhen.qu@futurewei.com
	Jeff Tantsura		Jeff Tantsura
	Microsoft		Microsoft
	Email: jefftant.ietf@gmail.com		Email: jefftant.ietf@gmail.com
	Acee Lindem		Acee Lindem
	Cisco		Cisco
	301 Midenhall Way		301 Midenhall Way
	Cary, NC 27513		Cary, NC 27513
	US		United States of America
	Email: acee@cisco.com		Email: acee@cisco.com
	Xufeng Liu		Xufeng Liu
	Volta Networks		Volta Networks
	Email: xufeng.liu.ietf@gmail.com		Email: xufeng.liu.ietf@gmail.com
End of changes. 169 change blocks.
	1350 lines changed or deleted		1325 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/