< draft-ietf-rtgwg-policy-model-27.txt		draft-ietf-rtgwg-policy-model-28.txt >
	RTGWG Y. Qu		RTGWG Y. Qu
	Internet-Draft Futurewei		Internet-Draft Futurewei
	Intended status: Standards Track J. Tantsura		Intended status: Standards Track J. Tantsura
	Expires: July 14, 2021 Apstra		Expires: December 9, 2021 Juniper Networks
	A. Lindem		A. Lindem
	Cisco		Cisco
	X. Liu		X. Liu
	Volta Networks		Volta Networks
	January 10, 2021		June 7, 2021
	A YANG Data Model for Routing Policy		A YANG Data Model for Routing Policy
	draft-ietf-rtgwg-policy-model-27		draft-ietf-rtgwg-policy-model-28
	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 which 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
	skipping to change at page 1, line 38 ¶		skipping to change at page 1, line 38 ¶
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at https://datatracker.ietf.org/drafts/current/.		Drafts is at https://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on July 14, 2021.		This Internet-Draft will expire on December 9, 2021.
	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
	skipping to change at page 2, line 24 ¶		skipping to change at page 2, line 24 ¶
	2.1. Tree Diagrams . . . . . . . . . . . . . . . . . . . . . . 4		2.1. Tree Diagrams . . . . . . . . . . . . . . . . . . . . . . 4
	2.2. Prefixes in Data Node Names . . . . . . . . . . . . . . . 5		2.2. Prefixes in Data Node Names . . . . . . . . . . . . . . . 5
	3. Model overview . . . . . . . . . . . . . . . . . . . . . . . 5		3. Model overview . . . . . . . . . . . . . . . . . . . . . . . 5
	4. Route policy expression . . . . . . . . . . . . . . . . . . . 6		4. Route policy expression . . . . . . . . . . . . . . . . . . . 6
	4.1. Defined sets for policy matching . . . . . . . . . . . . 6		4.1. Defined sets for policy matching . . . . . . . . . . . . 6
	4.2. Policy conditions . . . . . . . . . . . . . . . . . . . . 7		4.2. Policy conditions . . . . . . . . . . . . . . . . . . . . 7
	4.3. Policy actions . . . . . . . . . . . . . . . . . . . . . 8		4.3. Policy actions . . . . . . . . . . . . . . . . . . . . . 8
	4.4. Policy subroutines . . . . . . . . . . . . . . . . . . . 9		4.4. Policy subroutines . . . . . . . . . . . . . . . . . . . 9
	5. Policy evaluation . . . . . . . . . . . . . . . . . . . . . . 10		5. Policy evaluation . . . . . . . . . . . . . . . . . . . . . . 10
	6. Applying routing policy . . . . . . . . . . . . . . . . . . . 10		6. Applying routing policy . . . . . . . . . . . . . . . . . . . 10
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 11		7. YANG Module and Tree . . . . . . . . . . . . . . . . . . . . 11
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12		7.1. Routing Policy Model Tree . . . . . . . . . . . . . . . . 11
	9. YANG module . . . . . . . . . . . . . . . . . . . . . . . . . 12		7.2. Routing policy model . . . . . . . . . . . . . . . . . . 12
	9.1. Routing policy model . . . . . . . . . . . . . . . . . . 12		8. Security Considerations . . . . . . . . . . . . . . . . . . . 33
	10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 33		9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35
	11. References . . . . . . . . . . . . . . . . . . . . . . . . . 34		10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 35
	11.1. Normative references . . . . . . . . . . . . . . . . . . 34		11. References . . . . . . . . . . . . . . . . . . . . . . . . . 36
	11.2. Informative references . . . . . . . . . . . . . . . . . 36		11.1. Normative references . . . . . . . . . . . . . . . . . . 36
	Appendix A. Routing protocol-specific policies . . . . . . . . . 36		11.2. Informative references . . . . . . . . . . . . . . . . . 38
	Appendix B. Policy examples . . . . . . . . . . . . . . . . . . 39		Appendix A. Routing protocol-specific policies . . . . . . . . . 38
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 41		Appendix B. Policy examples . . . . . . . . . . . . . . . . . . 41
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 43
	1. Introduction		1. Introduction
	This document describes a YANG [RFC7950] data model for routing		This document describes a YANG [RFC7950] data model for routing
	policy configuration based on operational usage and best practices in		policy configuration based on operational usage and best practices in
	a variety of service provider networks. The model is intended to be		a variety of service provider networks. The model is intended to be
	vendor-neutral, in order to allow operators to manage policy		vendor-neutral, to allow operators to manage policy configuration in
	configuration in a consistent way in environments with routers		a consistent way in environments with routers supplied by multiple
	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 policy configuration parameters available in a variety of vendor		the policy configuration parameters available in a variety of vendor
	implementations, but supports widely used constructs for managing how		implementations, but supports widely used constructs for managing how
	routes are imported, exported, and modified across different routing		routes are imported, exported, and modified across different routing
	protocols. The model development approach has been to examine actual		protocols. The model development approach has been to examine actual
	policy configurations in use across a number of operator networks.		policy configurations in use across 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.
	skipping to change at page 5, line 35 ¶		skipping to change at page 5, line 35 ¶
	| | | |		| | | |
	| if-flex | ietf-if-flexible-encapsulation | [SUB-INTF-VLAN-YANG] |		| if-flex | ietf-if-flexible-encapsulation | [SUB-INTF-VLAN-YANG] |
	+---------+--------------------------------+----------------------+		+---------+--------------------------------+----------------------+
	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 to express policies as sets of related		o A generic framework is provided to express policies as sets of
	conditions and actions. This includes match sets and actions that		related conditions and actions. This includes match sets and
	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-		o A structure that allows routing protocol models to add protocol-
	specific policy conditions and actions though YANG augmentations.		specific policy conditions and actions though YANG augmentations
	There is a complete example of this for BGP [RFC4271] policies in		is also provided. There is a complete example of this for BGP
	the proposed vendor-neutral BGP data model		[RFC4271] policies in the proposed vendor-neutral BGP data model
	[I-D.ietf-idr-bgp-model].		[I-D.ietf-idr-bgp-model]. Appendix A provides an example of how
			an augmentation for BGP policies might be accomplished. Note that
			this section is not normative as the BGP model is still evolving.
	o A reusable grouping for attaching import and export rules in the		o Finally, a reusable grouping is defined for attaching import and
	context of routing configuration for different protocols, VRFs,		export rules in the context of routing configuration for different
	etc. This also enables creation of policy chains and expressing		protocols, VRFs, etc. This also enables creation of policy chains
	default policy behavior. In this document, policy chains are		and expressing default policy behavior. In this document, policy
	sequences of policy definitions that are applied in order		chains are sequences of policy definitions that are applied in
	(described in Section 4).		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.
	skipping to change at page 6, line 33 ¶		skipping to change at page 6, line 33 ¶
	+--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 models provide a set 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 which have their own defined
	sets. The supported defined sets include:		sets. The defined sets include:
	o prefix sets - Each prefix set defines a set of IP prefixes, each		o prefix sets - Each prefix set defines a set of IP prefixes, each
	with an associated IP prefix and netmask range (or exact length).		with an associated IP prefix and netmask range (or exact length).
	o neighbor sets - Each neighbor set define a set of neighboring		o neighbor sets - Each neighbor set defines a set of neighboring
	nodes by their IP addresses. A neighbor set is used for selecting		nodes 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		o tag set - Each tag set defines a set of generic tag values that
	can be used in matches for filtering routes.		can be used in matches for filtering routes.
	The model structure for defined sets is shown below.		The model structure for defined sets is shown below.
	+--rw routing-policy		+--rw routing-policy
	+--rw defined-sets		+--rw defined-sets
	skipping to change at page 7, line 31 ¶		skipping to change at page 7, line 31 ¶
	| +--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.		attributes against a specific value. The default action is to
			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		o 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		o ANY - match is true if the given value matches any member of the
	set.		set.
	skipping to change at page 8, line 11 ¶		skipping to change at page 8, line 11 ¶
	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 model,
	a restricted set of match options is used where applicable.		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 also 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
	skipping to change at page 9, line 33 ¶		skipping to change at page 9, line 33 ¶
	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 and evaluation of the policy continues (see Section 5). Note
	that the called policy may also modify attributes of the route in its		that the called policy may also modify attributes of the route in its
	action statements. Similarly, a reject-route action returns false		action statements. Similarly, a reject-route action returns false
	and the calling policy evaluation will be affected accordingly. When		and the calling policy evaluation will be affected accordingly. When
	the end of the subroutine policy statements is reached, the default		the end of the subroutine policy statements is reached, the default
	route disposition action is returned (i.e., boolean false for reject-		route disposition action is returned (i.e., Boolean false for reject-
	route). Consequently, a subroutine cannot explicitly accept or		route). Consequently, a subroutine cannot explicitly accept or
	reject a route. Rather it merely provides an indication that 'call-		reject a route. Rather, the called policy returns Boolean true if
	policy' condition returns boolean true or false indicating whether or		its outcome is accept-route or Boolean false if its outcome is
	not the condition matches. Route acceptance or rejection is solely		reject-route. Route acceptance or rejection is solely determined by
	determined by the top-level policy.		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., 2-3) is
	discouraged. Also, implementations should have validation to ensure		discouraged. Also, implementations MUST validate to ensure that
	that there is no recursion amongst nested routing policies.		there is no recursion amongst nested routing policies.
	5. Policy evaluation		5. Policy evaluation
	Evaluation of each policy definition proceeds by evaluating its		Evaluation of each policy definition proceeds by evaluating its
	corresponding individual policy statements in order. When all the		individual policy statements in order that they are defined. When
	condition statements in a policy statement are satisfied, the		all the condition statements in a policy statement are satisfied, the
	corresponding action statements are executed. If the actions include		corresponding action statements are executed. If the actions include
	either accept-route or reject-route actions, evaluation of the		either accept-route or reject-route actions, evaluation of the
	current policy definition stops, and no further policy statement is		current policy definition stops, and no further policy statement is
	evaluated. If there are multiple policies in the policy chain,		evaluated. If there are multiple policies in the policy chain,
	subsequent policies are not evaluated. Policy chains are sequences		subsequent policies are not evaluated. Policy chains are sequences
	of policy definitions (described in . (Section 4)).		of policy definitions (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).
	Note that the route's pre-policy attributes are always used for		Note that the route's pre-policy attributes are always used for
	testing policy statement conditions. In other words, if actions		testing policy statement conditions. In other words, if actions
	modify the policy application specific attributes, those		modify the policy application-specific attributes, those
	modifications are not used for policy statement conditions.		modifications are not used for policy statement conditions.
	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 specifying
	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. Security Considerations		7. YANG Module and Tree
	The YANG module specified in this document defines a schema for data		7.1. Routing Policy Model Tree
	that is designed to be accessed via network management protocols such
	as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer
	is the secure transport layer, and the mandatory-to-implement secure
	transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer
	is HTTPS, and the mandatory-to-implement secure transport is TLS
	[RFC8446].
	The NETCONF Access Control Model (NACM) [RFC8341] provides the means		The tree of the routing policy model is shown below.
	to restrict access for particular NETCONF or RESTCONF users to a pre-
	configured subset of all available NETCONF or RESTCONF protocol
	operations and content.
	There are a number of data nodes defined in this YANG module that are		module: ietf-routing-policy
	writable/creatable/deletable (i.e., config true, which is the		rw routing-policy
	default). These data nodes may be considered sensitive or vulnerable		+--rw defined-sets
	in some network environments. Write operations (e.g., edit-config)		| +--rw prefix-sets
	to these data nodes without proper protection can have a negative		| | +--rw prefix-set* [name mode]
	effect on network operations. These are the subtrees and data nodes		| | +--rw name string
	and their sensitivity/vulnerability:		| | +--rw mode enumeration
			| | +--rw prefixes
			| | +--rw prefix-list* [ip-prefix mask-length-lower
			| | mask-length-upper]
			| | +--rw ip-prefix inet:ip-prefix
			| | +--rw mask-length-lower uint8
			| | +--rw mask-length-upper uint8
			| +--rw neighbor-sets
			| | +--rw neighbor-set* [name]
			| | +--rw name string
			| | +--rw address* inet:ip-address
			| +--rw tag-sets
			| +--rw tag-set* [name]
			| +--rw name string
			| +--rw tag-value* tag-type
			+--rw policy-definitions
			+--rw policy-definition* [name]
			+--rw name string
			+--rw statements
			+--rw statement* [name]
			+--rw name string
			+--rw conditions
			| +--rw call-policy? -> ../../../../../..
			| /policy-definitions
			| /policy-definition/name
			| +--rw source-protocol? identityref
			| +--rw match-interface
			| | +--rw interface? -> /if:interfaces/interface
			| | /name
			| | +--rw subinterface? -> /if:interfaces/interface
			| | /if-ext:encapsulation
			| | /if-flex:flexible/match
			| | /dot1q-vlan-tagged
			| | /outer-tag/vlan-id
			| +--rw match-prefix-set
			| | +--rw prefix-set? -> ../../../../../../..
			| | /defined-sets/prefix-sets
			| | /prefix-set/name
			| | +--rw match-set-options? match-set-options-type
			| +--rw match-neighbor-set
			| | +--rw neighbor-set? -> ../../../../../../..
			| | /defined-sets/neighbor-sets
			| | /neighbor-set/name
			| +--rw match-tag-set
			| | +--rw tag-set? -> ../../../../../../..
			| | /defined-sets/tag-sets
			| | /tag-set/name
			| | +--rw match-set-options? match-set-options-type
			| +--rw match-route-type* identityref
			+--rw actions
			+--rw policy-result? policy-result-type
			+--rw set-metric
			| +--rw metric-modification? metric-modification-type
			| +--rw metric? uint32
			+--rw set-metric-type
			| +--rw metric-type? identityref
			+--rw set-route-level
			| +--rw route-level? identityref
			+--rw set-preference? uint16
			+--rw set-tag? tag-type
			+--rw set-application-tag? tag-type
	/routing-policy		7.2. Routing policy model
	/routing-policy/defined-sets/prefix-sets		The following RFCs are not referenced in the document text but are
			referenced in the ietf-routing-policy.yang module: [RFC2328],
			[RFC3101], [RFC5130], [RFC5302], [RFC6991], and [RFC8343].
	/routing-policy/defined-sets/neighbor-sets		<CODE BEGINS> file "ietf-routing-policy@2021-06-07.yang"
			module ietf-routing-policy {
	/routing-policy/defined-sets/tag-sets		yang-version "1.1";
	/routing-policy/policy-definitions		namespace "urn:ietf:params:xml:ns:yang:ietf-routing-policy";
			prefix rt-pol;
			import ietf-inet-types {
			prefix "inet";
			reference "RFC 6991: Common YANG Data Types";
			}
	Unauthorized access to any data node of these subtrees can disclose		import ietf-yang-types {
	the operational state information of routing policies on this device.		prefix "yang";
			reference "RFC 6991: Common YANG Data Types";
			}
	Routing policy configuration has a significant impact on network		import ietf-interfaces {
	operations, and, as such, any related model carries potential		prefix "if";
	security risks. Unauthorized access or invalid data could cause		reference "RFC 8343: A YANG Data Model for Interface
	major disruption.		Management (NMDA Version)";
			}
	8. IANA Considerations		import ietf-routing {
			prefix "rt";
			reference "RFC 8349: A YANG Data Model for Routing
			Management (NMDA Version)";
			}
	This document registers a URI in the IETF XML registry [RFC3688].		import ietf-if-extensions {
	Following the format in [RFC3688], the following registration is		prefix "if-ext";
	requested to be made:		reference "RFC YYYY: Common Interface Extension YANG
			Data Models. Please replace YYYY with
			published RFC number for
			draft-ietf-netmod-intf-ext-yang.";
			}
	URI: urn:ietf:params:xml:ns:yang:ietf-routing-policy		import ietf-if-flexible-encapsulation {
	Registrant Contact: The IESG.		prefix "if-flex";
	XML: N/A, the requested URI is an XML namespace.		reference "RFC ZZZZ: Sub-interface VLAN YANG Data Models.
			Please replace ZZZZ with published RFC number
			for draft-ietf-netmod-sub-intf-vlan-model.";
			}
	This document registers a YANG module in the YANG Module Names		organization
	registry [RFC6020].		"IETF RTGWG - Routing Area Working Group";
			contact
			"WG Web: <https://datatracker.ietf.org/wg/rtgwg/>
			WG List: <mailto: rtgwg@ietf.org>
	name: ietf-routing-policy		Editor: Yingzhen Qu
	namespace: urn:ietf:params:xml:ns:yang:ietf-routing-policy		<mailto: yingzhen.qu@futurewei.com>
	prefix: rt-pol		Jeff Tantsura
	reference: RFC XXXX		<mailto: jefftant.ietf@gmail.com>
			Acee Lindem
			<mailto: acee@cisco.com>
			Xufeng Liu
			<mailto: xufeng.liu.ietf@gmail.com>";
	9. YANG module		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.
	The routing policy model is described by the YANG modules in the		This YANG module conforms to the Network Management
	sections below. [RFC2328], [RFC3101], [RFC5130], and [RFC5302] are		Datastore Architecture (NMDA), as described in RFC 8342.
	referenced here since they are referenced in the YANG model but not
	elsewhere in this document.
	9.1. Routing policy model		Copyright (c) 2021 IETF Trust and the persons identified as
			authors of the code. All rights reserved.
	<CODE BEGINS> file "ietf-routing-policy@2021-01-10.yang"		Redistribution and use in source and binary forms, with or
	module ietf-routing-policy {		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).
	yang-version "1.1";		This version of this YANG module is part of RFC XXXX;
			see the RFC itself for full legal notices.
	namespace "urn:ietf:params:xml:ns:yang:ietf-routing-policy";		The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL
	prefix rt-pol;		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.";
	import ietf-inet-types {		reference "RFC XXXX: A YANG Data Model for Routing Policy.";
	prefix "inet";
	reference "RFC 6991: Common YANG Data Types";
	}
	import ietf-yang-types {		revision "2021-06-07" {
	prefix "yang";		description
	reference "RFC 6991: Common YANG Data Types";		"Initial revision.";
	}		reference
	import ietf-interfaces {		"RFC XXXX: A YANG Data Model for Routing Policy Management.";
	prefix "if";		}
	reference "RFC 8343: A YANG Data Model for Interface
	Management (NMDA Version)";
	}
	import ietf-routing {		/* Identities */
	prefix "rt";		identity metric-type {
	reference "RFC 8349: A YANG Data Model for Routing		description
	Management (NMDA Version)";		"Base identity for route metric types.";
	}		}
	import ietf-if-extensions {		identity ospf-type-1-metric {
	prefix "if-ext";		base metric-type;
	reference "RFC YYYY: Common Interface Extension YANG		description
	Data Models. Please replace YYYY with		"Identity for the OSPF type 1 external metric types. It
	published RFC number for		is only applicable to OSPF routes.";
	draft-ietf-netmod-intf-ext-yang.";		reference
	}		"RFC 2328 - OSPF Version 2";
			}
	import ietf-if-flexible-encapsulation {		identity ospf-type-2-metric {
	prefix "if-flex";		base metric-type;
	reference "RFC ZZZZ: Sub-interface VLAN YANG Data Models.		description
	Please replace ZZZZ with published RFC number		"Identity for the OSPF type 2 external metric types. It
	for draft-ietf-netmod-sub-intf-vlan-model.";		is only applicable to OSPF routes.";
	}		reference
			"RFC 2328 - OSPF Version 2";
			}
	organization		identity isis-internal-metric {
	"IETF RTGWG - Routing Area Working Group";		base metric-type;
	contact		description
	"WG Web: <http://tools.ietf.org/wg/rtgwg/>		"Identity for the IS-IS internal metric types. It is only
	WG List: <Email: rtgwg@ietf.org>		applicable to IS-IS routes.";
			reference
			"RFC 5302 - Domain-Wide Prefix Distribution with
			Two-Level IS-IS";
			}
	Editor: Yingzhen Qu		identity isis-external-metric {
	<Email: yingzhen.qu@futurewei.com>		base metric-type;
	Jeff Tantsura		description
	<Email: jefftant.ietf@gmail.com>		"Identity for the IS-IS external metric types. It is only
	Acee Lindem		applicable to IS-IS routes.";
	<Email: acee@cisco.com>		reference
	Xufeng Liu		"RFC 5302 - Domain-Wide Prefix Distribution with
	<Email: xufeng.liu.ietf@gmail.com>";		Two-Level IS-IS";
			}
	description		identity route-level {
	"This module describes a YANG model for routing policy		description
	configuration. It is a limited subset of all of the policy		"Base identity for route import level.";
	configuration parameters available in the variety of vendor		}
	implementations, but supports widely used constructs for		identity ospf-normal {
	managing how routes are imported, exported, modified and		base route-level;
	advertised across different routing protocol instances or		description
	within a single routing protocol instance. This module is		"Identity for OSPF importation into normal areas
	intended to be used in conjunction with routing protocol		It is only applicable to routes imported
	configuration modules (e.g., BGP) defined in other models.		into the OSPF protocol.";
			reference
			"RFC 2328 - OSPF Version 2";
			}
	Route policy expression:		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";
			}
	Policies are expressed as a set of top-level policy		identity ospf-normal-nssa {
	definitions, each of which consists of a sequence of policy		base route-level;
	statements. Policy statements consist of simple		description
	condition-action tuples. Conditions may include multiple match		"Identity for OSPF importation into both normal and NSSA
	or comparison operations. Actions may include changes to route		areas, it is only applicable to routes imported into
	attributes as well as a final disposition of accepting or		the OSPF protocol.";
	rejecting the route.		reference
			"RFC 3101: The OSPF Not-So-Stubby Area (NSSA) Option";
			}
	Route policy evaluation:		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";
			}
	Policy definitions are referenced in routing protocol		identity isis-level-2 {
	configurations using import and export configuration		base route-level;
	statements. The arguments are members of an ordered list of		description
	named policy definitions which comprise a policy chain, and		"Identity for IS-IS Level 2 area importation. It is only
	optionally, an explicit default policy action (i.e., reject		applicable to routes imported into the IS-IS protocol.";
	or accept).		reference
			"RFC 5302 - Domain-Wide Prefix Distribution with
			Two-Level IS-IS";
	Evaluation of each policy definition proceeds by evaluating		}
	its corresponding individual policy statements in order. When
	a condition statement in a policy statement is satisfied, the
	corresponding action statement is executed. If the action
	statement has either accept-route or reject-route actions,
	policy evaluation of the current policy definition stops, and
	no further policy definitions in the chain are evaluated.
	If the condition is not satisfied, then evaluation proceeds to		identity isis-level-1-2 {
	the next policy statement. If none of the policy statement		base route-level;
	conditions are satisfied, then evaluation of the current		description
	policy definition stops, and the next policy definition in the		"Identity for IS-IS Level 1 and Level 2 area importation. It
	chain is evaluated. When the end of the policy chain is		is only applicable to routes imported into the IS-IS
	reached, the default route disposition action is performed		protocol.";
	(i.e., reject-route unless an alternate default action is		reference
	specified for the chain).		"RFC 5302 - Domain-Wide Prefix Distribution with
			Two-Level IS-IS";
			}
	Policy 'subroutines' (or nested policies) are supported by		identity proto-route-type {
	allowing policy statement conditions to reference another		description
	policy definition which applies conditions and actions from		"Base identity for route type within a protocol.";
	the referenced policy before returning to the calling policy		}
	statement and resuming evaluation. If the called policy
	results in an accept-route (either explicit or by default),
	then the subroutine returns an effective true value to the
	calling policy. Similarly, a reject-route action returns
	false. If the subroutine returns true, the calling policy
	continues to evaluate the remaining conditions with the initial
	data if route attribute values are modified.
	Copyright (c) 2021 IETF Trust and the persons identified as		identity isis-level-1-type {
	authors of the code. All rights reserved.		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";
			}
	Redistribution and use in source and binary forms, with or		identity isis-level-2-type {
	without modification, is permitted pursuant to, and subject to		base proto-route-type;
	the license terms contained in, the Simplified BSD License set		description
	forth in Section 4.c of the IETF Trust's Legal Provisions		"Identity for IS-IS Level 2 route type. It is only
	Relating to IETF Documents		applicable to IS-IS routes.";
	(https://trustee.ietf.org/license-info).		reference
			"RFC 5302 - Domain-Wide Prefix Distribution with
			Two-Level IS-IS";
			}
	This version of this YANG module is part of RFC XXXX		identity ospf-internal-type {
	(https://www.rfc-editor.org/info/rfcXXXX); see the RFC itself		base proto-route-type;
	for full legal notices.		description
			"Identity for OSPF intra-area or inter-area route type.
			It is only applicable to OSPF routes.";
			reference
			"RFC 2328 - OSPF Version 2";
			}
	The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL		identity ospf-external-type {
	NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT		base proto-route-type;
	RECOMMENDED', 'MAY', and 'OPTIONAL' in this document are to be		description
	interpreted as described in BCP 14 (RFC 2119) (RFC 8174) when,		"Identity for OSPF external type 1/2 route type.
	and only when, they appear in all capitals, as shown here.		It is only applicable to OSPF routes.";
			reference
			"RFC 2328 - OSPF Version 2";
			}
	This version of this YANG module is part of RFC XXXX;		identity ospf-external-t1-type {
	see the RFC itself for full legal notices.";		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";
			}
	revision "2021-01-10" {		identity ospf-external-t2-type {
	description		base ospf-external-type;
	"Initial revision.";		description
	reference		"Identity for OSPF external type 2 route type.
	"RFC XXXX: A YANG Data Model for Routing Policy Management.";		It is only applicable to OSPF routes.";
	}		reference
			"RFC 2328 - OSPF Version 2";
			}
	/* Identities */		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 metric-type {		identity ospf-nssa-t1-type {
	description		base ospf-nssa-type;
	"Base identity for route metric types.";		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-type-1-metric {		identity ospf-nssa-t2-type {
	base metric-type;		base ospf-nssa-type;
	description		description
	"Identity for the OSPF type 1 external metric types. It		"Identity for OSPF NSSA type 2 route type.
	is only applicable to OSPF routes.";
	reference
	"RFC 2328 - OSPF Version 2";
	}
	identity ospf-type-2-metric {		It is only applicable to OSPF routes.";
	base metric-type;		reference
	description		"RFC 3101: The OSPF Not-So-Stubby Area (NSSA) Option";
	"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 {		identity bgp-internal {
	base metric-type;		base proto-route-type;
	description		description
	"Identity for the IS-IS internal metric types. It is only		"Identity for routes learned from internal BGP (IBGP).
	applicable to IS-IS routes.";		It is only applicable to BGP routes.";
	reference		reference
	"RFC 5302 - Domain-Wide Prefix Distribution with		"RFC 4271: A Border Gateway Protocol 4 (BGP-4)";
	Two-Level IS-IS";		}
	}
	identity isis-external-metric {		identity bgp-external {
	base metric-type;		base proto-route-type;
	description		description
	"Identity for the IS-IS external metric types. It is only		"Identity for routes learned from external BGP (EBGP).
	applicable to IS-IS routes.";		It is only applicable to BGP routes.";
	reference		reference
	"RFC 5302 - Domain-Wide Prefix Distribution with		"RFC 4271: A Border Gateway Protocol 4 (BGP-4)";
	Two-Level IS-IS";		}
	}
	identity route-level {		/* Type Definitions */
	description
	"Base identity for route import or export level.";
	}
	identity ospf-normal {		typedef default-policy-type {
	base route-level;		type enumeration {
	description		enum accept-route {
	"Identity for OSPF importation into normal areas		description
	It is only applicable to routes imported		"Default policy to accept the route.";
	into the OSPF protocol.";		}
	reference		enum reject-route {
	"RFC 2328 - OSPF Version 2";		description
	}		"Default policy to reject the route.";
	identity ospf-nssa-only {		}
	base route-level;		}
	description		description
	"Identity for the OSPF Not-So-Stubby Area (NSSA) area		"Type used to specify route disposition in
	importation. It is only applicable to routes imported		a policy chain. This typedef is used in
	into the OSPF protocol.";		the default import and export policy.";
	reference		}
	"RFC 3101: The OSPF Not-So-Stubby Area (NSSA) Option";
	}
	identity ospf-normal-nssa {		typedef policy-result-type {
	base route-level;		type enumeration {
	description		enum accept-route {
	"Identity for OSPF importation into both normal and NSSA		description
	areas, it is only applicable to routes imported into		"Policy accepts the route.";
	the OSPF protocol.";		}
	reference		enum reject-route {
	"RFC 3101: The OSPF Not-So-Stubby Area (NSSA) Option";		description
	}		"Policy rejects the route.";
			}
			}
			description
			"Type used to specify route disposition in
			a policy chain.";
			}
	identity isis-level-1 {		typedef tag-type {
	base route-level;		type union {
	description		type uint32;
	"Identity for IS-IS Level 1 area importation. It is only		type yang:hex-string;
	applicable to routes imported into the IS-IS protocol.";		}
	reference		description
	"RFC 5302 - Domain-Wide Prefix Distribution with		"Type for expressing route tags on a local system,
	Two-Level IS-IS";		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";
			}
	identity isis-level-2 {		typedef match-set-options-type {
	base route-level;		type enumeration {
	description		enum any {
	"Identity for IS-IS Level 2 area importation. It is only		description
	applicable to routes imported into the IS-IS protocol.";		"Match is true if given value matches any member
	reference		of the defined set.";
	"RFC 5302 - Domain-Wide Prefix Distribution with		}
	Two-Level IS-IS";		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.";
	identity isis-level-1-2 {		}
	base route-level;
	description
	"Identity for IS-IS Level 1 and 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 proto-route-type {		typedef metric-modification-type {
	description		type enumeration {
	"Base identity for route type within a protocol.";		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 would overflow 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 would be less than 0, set the metric to 0.";
			}
			}
			description
			"Type used to specify how to set the metric given the
			specified value.";
			}
	identity isis-level-1-type {		/* Groupings */
	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 {		grouping prefix {
	base proto-route-type;		description
	description		"Configuration data for a prefix definition.
	"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 {		The combination of mask-length-lower and mask-length-upper
	base proto-route-type;		define a range for the mask length, or single 'exact'
	description		length if mask-length-lower and mask-length-upper are
	"Identity for OSPF intra-area or inter-area route type.		equal.
	It is only applicable to OSPF routes.";
	reference
	"RFC 2328 - OSPF Version 2";
	}
	identity ospf-external-type {		Example: 192.0.2.0/24 through 192.0.2.0/26 would be
	base proto-route-type;		expressed as prefix: 192.0.2.0/24,
	description		mask-length-lower=24,
	"Identity for OSPF external type 1/2 route type.		mask-length-upper=26
	It is only applicable to OSPF routes.";
	reference
	"RFC 2328 - OSPF Version 2";
	}
	identity ospf-external-t1-type {		Example: 192.0.2.0/24 (an exact match) would be
	base ospf-external-type;		expressed as prefix: 192.0.2.0/24,
	description		mask-length-lower=24,
	"Identity for OSPF external type 1 route type.		mask-length-upper=24
	It is only applicable to OSPF routes.";
	reference
	"RFC 2328 - OSPF Version 2";
	}
	identity ospf-external-t2-type {		Example: 2001:DB8::/32 through 2001:DB8::/64 would be
	base ospf-external-type;		expressed as prefix: 2001:DB8::/32,
	description		mask-length-lower=32,
	"Identity for OSPF external type 2 route type.		mask-length-upper=64";
	It is only applicable to OSPF routes.";
	reference
	"RFC 2328 - OSPF Version 2";
	}
	identity ospf-nssa-type {		leaf ip-prefix {
	base proto-route-type;		type inet:ip-prefix;
	description		mandatory true;
	"Identity for OSPF NSSA type 1/2 route type.		description
	It is only applicable to OSPF routes.";		"The IP prefix represented as an IPv6 or IPv4 network
	reference		number followed by a prefix length with an intervening
	"RFC 3101: The OSPF Not-So-Stubby Area (NSSA) Option";		slash character as a delimiter. All members of the
	}		prefix-set MUST be of the same address family as the
			prefix-set mode.";
			}
	identity ospf-nssa-t1-type {		leaf mask-length-lower {
	base ospf-nssa-type;		type uint8 {
	description		range "0..128";
	"Identity for OSPF NSSA type 1 route type.		}
	It is only applicable to OSPF routes.";		description
	reference		"Mask length range lower bound. It MUST NOT be less than
	"RFC 3101: The OSPF Not-So-Stubby Area (NSSA) Option";		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.";
			}
			}
	identity ospf-nssa-t2-type {		grouping match-set-options-group {
	base ospf-nssa-type;		description
	description		"Grouping containing options relating to how a particular set
	"Identity for OSPF NSSA type 2 route type.		will be matched.";
	It is only applicable to OSPF routes.";
	reference
	"RFC 3101: The OSPF Not-So-Stubby Area (NSSA) Option";
	}
	identity bgp-internal {		leaf match-set-options {
	base proto-route-type;		type match-set-options-type;
	description		description
	"Identity for routes learned from internal BGP (IBGP).		"Optional parameter that governs the behavior of the
	It is only applicable to BGP routes.";		match operation.";
			}
			}
			grouping match-set-options-restricted-group {
			description
			"Grouping for a restricted set of match operation
			modifiers.";
	reference		leaf match-set-options {
	"RFC 4271: A Border Gateway Protocol 4 (BGP-4)";		type match-set-options-type {
	}		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.";
			}
			}
	identity bgp-external {		grouping match-interface-condition {
	base proto-route-type;		description
	description		"This grouping provides interface match condition.";
	"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 */		container match-interface {
			leaf interface {
			type leafref {
			path "/if:interfaces/if:interface/if:name";
			}
			description
			"Reference to a base interface. If a reference to a
			subinterface is required, this leaf MUST be specified
			to indicate the base interface.";
			}
			leaf subinterface {
			type leafref {
			path "/if:interfaces/if:interface/if-ext:encapsulation"
			+ "/if-flex:flexible/if-flex:match"
			+ "/if-flex:dot1q-vlan-tagged"
			+ "/if-flex:outer-tag/if-flex:vlan-id";
			}
			description
			"Reference to a subinterface -- this requires the base
			interface to be specified using the interface leaf in
			this container. If only a reference to a base interface
			is required, this leaf MUST NOT be set.";
			}
	typedef default-policy-type {		description
	type enumeration {		"Container for interface match conditions";
	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 retained for
	name compatibility with default import and
	export policy.";
	}
	typedef policy-result-type {		grouping match-route-type-condition {
	type enumeration {		description
	enum accept-route {		"This grouping provides route-type match condition";
	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 {		leaf-list match-route-type {
	type enumeration {		type identityref {
	enum any {		base proto-route-type;
	description		}
	"Match is true if given value matches any member		description
	of the defined set.";		"Condition to check the protocol-specific type
	}		of route. This is normally used during route
	enum all {		importation to select routes or to set protocol
	description		specific attributes based on the route type.";
	"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 {		grouping prefix-set-condition {
	type enumeration {		description
	enum set-metric {		"This grouping provides prefix-set conditions.";
	description
	"Set the metric to the specified value.";
	}
	enum add-metric {
	description
	"Add the specified value to the existing metric.
	If the result would overflow 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 would be less than 0, set the metric to 0.";
	}
	}
	description
	"Type used to specify how to set the metric given the
	specified value.";
	}
	/* Groupings */		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;
	grouping prefix {		description
	description		"Match a referenced prefix-set according to the logic
	"Configuration data for a prefix definition.";		defined in the match-set-options leaf.";
			}
			}
			grouping neighbor-set-condition {
			description
			"This grouping provides neighbor-set conditions.";
	leaf ip-prefix {		container match-neighbor-set {
	type inet:ip-prefix;		leaf neighbor-set {
	mandatory true;		type leafref {
	description		path "../../../../../../../defined-sets/neighbor-sets/" +
	"The IP prefix represented as an IPv6 or IPv4 network		"neighbor-set/name";
	number followed by a prefix length with an intervening		require-instance true;
	slash character as a delimiter. All members of the prefix		}
	set MUST be of the same address family as the prefix-set		description
	mode.";		"References a defined neighbor set.";
	}		}
	leaf mask-length-lower {		description
	type uint8;		"Match a referenced neighbor set according to the logic
	description		defined in the match-set-options-leaf.";
	"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.
	The combination of mask-length-lower and mask-length-upper		grouping tag-set-condition {
	define a range for the mask length, or single 'exact'		description
	length if mask-length-lower and mask-length-upper are		"This grouping provides tag-set conditions.";
	equal.
	Example: 192.0.2.0/24 through 192.0.2.0/26 would be		container match-tag-set {
	expressed as prefix: 192.0.2.0/24,		leaf tag-set {
	mask-length-lower=24,		type leafref {
	mask-length-upper=26		path "../../../../../../../defined-sets/tag-sets" +
			"/tag-set/name";
			require-instance true;
			}
			description
			"References a defined tag set.";
			}
			uses match-set-options-group;
	Example: 192.0.2.0/24 (an exact match) would be		description
	expressed as prefix: 192.0.2.0/24,		"Match a referenced tag set according to the logic defined
	mask-length-lower=24,		in the match-options-set leaf.";
	mask-length-upper=24";		}
	}		}
	}
	grouping match-set-options-group {		grouping apply-policy-import {
	description		description
	"Grouping containing options relating to how a particular set		"Grouping for applying import policies.";
	will be matched.";
	leaf match-set-options {		leaf-list import-policy {
	type match-set-options-type;		type leafref {
	description		path "/rt-pol:routing-policy/rt-pol:policy-definitions/" +
	"Optional parameter that governs the behavior of the		"rt-pol:policy-definition/rt-pol:name";
	match operation.";		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.";
			}
	grouping match-set-options-restricted-group {		leaf default-import-policy {
	description		type default-policy-type;
	"Grouping for a restricted set of match operation		default reject-route;
	modifiers.";		description
			"Explicitly set a default policy if no policy definition
			in the import policy chain is satisfied.";
			}
	leaf match-set-options {		}
	type match-set-options-type {
	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 match-interface-condition {		grouping apply-policy-export {
	description		description
	"This grouping provides interface match condition.";		"Grouping for applying export policies.";
	container match-interface {		leaf-list export-policy {
	leaf interface {		type leafref {
	type leafref {		path "/rt-pol:routing-policy/rt-pol:policy-definitions/" +
	path "/if:interfaces/if:interface/if:name";		"rt-pol:policy-definition/rt-pol:name";
	}		require-instance true;
	description		}
	"Reference to a base interface. If a reference to a		ordered-by user;
	subinterface is required, this leaf MUST be specified		description
	to indicate the base interface.";		"List of policy names in sequence to be applied on
	}		redistributing routes from one routing protocol to another
	leaf subinterface {		or sending a routing update in the current context, e.g.,
	type leafref {		for the current peer group, neighbor, address family,
	path "/if:interfaces/if:interface/if-ext:encapsulation"		etc.";
	+ "/if-flex:flexible/if-flex:match"		}
	+ "/if-flex:dot1q-vlan-tagged"
	+ "/if-flex:outer-tag/if-flex:vlan-id";
	}
	description
	"Reference to a subinterface -- this requires the base
	interface to be specified using the interface leaf in
	this container. If only a reference to a base interface
	is required, this leaf SHOULD NOT be set.";
	}
	description		leaf default-export-policy {
	"Container for interface match conditions";		type default-policy-type;
	}		default reject-route;
	}		description
			"Explicitly set a default policy if no policy definition
			in the export policy chain is satisfied.";
			}
			}
	grouping match-route-type-condition {		grouping apply-policy-group {
	description		description
	"This grouping provides route-type match condition";		"Top level container for routing policy applications. This
			grouping is intended to be used in routing models where
			needed.";
	leaf-list match-route-type {		container apply-policy {
	type identityref {		description
	base proto-route-type;		"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.";
	}		uses apply-policy-import;
	description		uses apply-policy-export;
	"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.";
	}
	}
	grouping prefix-set-condition {		}
	description		}
	"This grouping provides prefix-set conditions.";
	container match-prefix-set {		container routing-policy {
	leaf prefix-set {		description
	type leafref {		"Top-level container for all routing policy.";
	path "../../../../../../../defined-sets/" +
	"prefix-sets/prefix-set/name";
	}
	description
	"References a defined prefix set.";
	}
	uses match-set-options-restricted-group;
	description		container defined-sets {
	"Match a referenced prefix-set according to the logic		description
	defined in the match-set-options leaf.";		"Predefined sets of attributes used in policy match
	}		statements.";
	}
	grouping neighbor-set-condition {		container prefix-sets {
	description		description
	"This grouping provides neighbor-set conditions.";		"Data definitions for a list of IPv4 or IPv6
			prefixes which are matched as part of a policy.";
			list prefix-set {
			key "name mode";
			description
			"List of the defined prefix sets";
	container match-neighbor-set {		leaf name {
	leaf neighbor-set {		type string;
	type leafref {		description
	path "../../../../../../../defined-sets/neighbor-sets/" +		"Name of the prefix set -- this is used as a label to
	"neighbor-set/name";		reference the set in match conditions.";
	require-instance true;		}
	}		leaf mode {
	description		type enumeration {
	"References a defined neighbor set.";		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, IPv6, or both) 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.";
			}
	description		container prefixes {
	"Match a referenced neighbor set according to the logic		description
	defined in the match-set-options-leaf.";		"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.";
	grouping tag-set-condition {		uses prefix;
	description		}
	"This grouping provides tag-set conditions.";		}
			}
			}
	container match-tag-set {		container neighbor-sets {
	leaf tag-set {		description
	type leafref {		"Data definition for a list of IPv4 or IPv6
	path "../../../../../../../defined-sets/tag-sets" +		neighbors which can be matched in a routing policy.";
	"/tag-set/name";
	require-instance true;
	}
	description
	"References a defined tag set.";
	}
	uses match-set-options-restricted-group;
	description		list neighbor-set {
	"Match a referenced tag set according to the logic defined		key "name";
	in the match-options-set leaf.";		description
	}		"List of defined neighbor sets for use in policies.";
	}
	grouping apply-policy-import {		leaf name {
	description		type string;
	"Grouping for applying import policies.";		description
			"Name of the neighbor set -- this is used as a label
			to reference the set in match conditions.";
			}
	leaf-list import-policy {		leaf-list address {
	type leafref {		type inet:ip-address;
	path "/rt-pol:routing-policy/rt-pol:policy-definitions/" +		description
	"rt-pol:policy-definition/rt-pol:name";		"List of IP addresses in the neighbor set.";
	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 {		container tag-sets {
	type default-policy-type;		description
	default reject-route;		"Data definitions for a list of tags which can
	description		be matched in policies.";
	"Explicitly set a default policy if no policy definition
	in the import policy chain is satisfied.";
	}
	}		list tag-set {
			key "name";
			description
			"List of tag set definitions.";
	grouping apply-policy-export {		leaf name {
	description		type string;
	"Grouping for applying export policies.";		description
			"Name of the tag set -- this is used as a label to
			reference the set in match conditions.";
			}
	leaf-list export-policy {		leaf-list tag-value {
	type leafref {		type tag-type;
	path "/rt-pol:routing-policy/rt-pol:policy-definitions/" +		description
	"rt-pol:policy-definition/rt-pol:name";		"Value of the tag set member.";
	require-instance true;		}
	}		}
	ordered-by user;		}
	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 {		container policy-definitions {
	type default-policy-type;		description
	default reject-route;		"Enclosing container for the list of top-level policy
	description		definitions.";
	"Explicitly set a default policy if no policy definition
	in the export policy chain is satisfied.";
	}
	}
	grouping apply-policy-group {		list policy-definition {
	description		key "name";
	"Top level container for routing policy applications. This		description
	grouping is intended to be used in routing models where		"List of top-level policy definitions, keyed by unique
	needed.";		name. These policy definitions are expected to be
			referenced (by name) in policy chains specified in
			import or export configuration statements.";
	container apply-policy {		leaf name {
	description		type string;
	"Anchor point for routing policies in the model.		description
	Import and export policies are with respect to the local		"Name of the top-level policy definition -- this name
	routing table, i.e., export (send) and import (receive),		is used in references to the current policy.";
	depending on the context.";		}
	uses apply-policy-import;		container statements {
	uses apply-policy-export;		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 (see the description of policy
			evaluation at the top of this module.";
	container routing-policy {		leaf name {
	description		type string;
	"Top-level container for all routing policy.";		description
			"Name of the policy statement.";
			}
	container defined-sets {		container conditions {
	description		description
	"Predefined sets of attributes used in policy match		"Condition statements for the current policy
	statements.";		statement.";
	container prefix-sets {		leaf call-policy {
	description		type leafref {
	"Data definitions for a list of IPv4 or IPv6		path "../../../../../../" +
	prefixes which are matched as part of a policy.";		"rt-pol:policy-definitions/" +
	list prefix-set {		"rt-pol:policy-definition/rt-pol:name";
	key "name mode";		require-instance true;
	description		}
	"List of the defined prefix sets";		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.";
			}
	leaf name {		leaf source-protocol {
	type string;		type identityref {
	description		base rt:control-plane-protocol;
	"Name of the prefix set -- this is used as a label to		}
	reference the set in match conditions.";		description
	}		"Condition to check the protocol / method used to
			install the route into the local routing table.";
			}
	leaf mode {		uses match-interface-condition;
	type enumeration {		uses prefix-set-condition;
	enum ipv4 {		uses neighbor-set-condition;
	description		uses tag-set-condition;
	"Prefix set contains IPv4 prefixes only.";		uses match-route-type-condition;
	}		}
	enum ipv6 {
	description
	"Prefix set contains IPv6 prefixes only.";
	}
	}
	description
	"Indicates the mode of the prefix set, in terms of
	which address families (IPv4, IPv6, or both) are
	present. The mode provides a hint, but the device
	MUST validate that all prefixes are of the indicated
	type, and is expected to reject the configuration if
	there is a discrepancy.";
	}		container actions {
			description
			"Top-level container for policy action
			statements.";
			leaf policy-result {
			type policy-result-type;
			default reject-route;
			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-preference {
			type uint16;
			description
			"Set the preference for the route. It is also
			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.";
			}
			}
			}
			}
			}
			}
			}
			}
			<CODE ENDS>
	container prefixes {		8. Security Considerations
	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 {		The YANG module specified in this document defines a schema for data
	key "ip-prefix mask-length-lower mask-length-upper";		that is designed to be accessed via network management protocols such
	description		as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer
	"List of prefixes in the prefix set.";		is the secure transport layer, and the mandatory-to-implement secure
			transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer
			is HTTPS, and the mandatory-to-implement secure transport is TLS
			[RFC8446].
	uses prefix;		The NETCONF Access Control Model (NACM) [RFC8341] provides the means
	}		to restrict access for particular NETCONF or RESTCONF users to a pre-
	}		configured subset of all available NETCONF or RESTCONF protocol
	}		operations and content.
	}
	container neighbor-sets {		There are a number of data nodes defined in this YANG module that are
	description		writable/creatable/deletable (i.e., config true, which is the
	"Data definition for a list of IPv4 or IPv6		default). These data nodes may be considered sensitive or vulnerable
	neighbors which can be matched in a routing policy.";		in some network environments. Write operations (e.g., edit-config)
			to these data nodes without proper protection can have a negative
			effect on network operations. These are the subtrees and data nodes
			and their sensitivity/vulnerability:
	list neighbor-set {		/routing-policy
	key "name";
	description
	"List of defined neighbor sets for use in policies.";
	leaf name {		/routing-policy/defined-sets/prefix-sets -- Modification to
	type string;		prefix-sets could result in a Denial-of-Service (DoS) attack. An
	description		attacker may try to modify prefix-sets and redirect or drop
	"Name of the neighbor set -- this is used as a label		traffic. Redirection of traffic could be used as part of a more
	to reference the set in match conditions.";		elaborate attack to either collect sensitive information or
	}		masquerade a service. Additionally, a control-plane DoS attack
			could be accomplished by allowing a large number of routes to be
			leaked into a routing protocol domian (e.g., BGP).
	leaf-list address {		/routing-policy/defined-sets/neighbor-sets -- Modification to the
	type inet:ip-address;		neighbor-sets could be used to mount a DoS attack or more
	description		elaborate attack as with prefix-sets. For example, a DoS attack
	"List of IP addresses in the neighbor set.";		could be mounted by changing the neighbor-set from which routes
	}		are accepted.
	}
	}
	container tag-sets {
	description
	"Data definitions for a list of tags which can
	be matched in policies.";
	list tag-set {		/routing-policy/defined-sets/tag-sets -- Modification to the tag-
	key "name";		sets could be used to mount a DoS attack. Routes with certain
	description		tags might be redirected or dropped. The implications are similar
	"List of tag set definitions.";		to prefix-sets and neighbor-sets. However, the attack may be more
			difficult to detect as the routing policy usage of route tags and
			intent must be understood to recognize the breach. Conversely,
			the implications of prefix-set or neighbor set modification are
			easier to recognize.
	leaf name {		/routing-policy/policy-definitions
	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 {		/routing-policy/policy-definitions/policy-definition
	type tag-type;		/statements/statement/conditions -- Modification to the conditions
	description		could be used to mount a DoS attack or other attack. An attacker
	"Value of the tag set member.";		may change a policy condition and redirect or drop traffic. As
	}		with prefix-sets, neighbor-sets, or tag-sets, traffic redirection
	}		could be used as part of a more elaborate attack.
	}
	}
	container policy-definitions {		/routing-policy/policy-definitions/policy-definition
	description		/statements/statement/actions -- Modification to actions could be
	"Enclosing container for the list of top-level policy		used to mount a DoS attack or other attack. Traffic may be
	definitions.";		redirected or dropped. As with prefix-sets, neighbor-sets, or
			tag-sets, traffic redirection could be used as part of a more
			elaborate attack. Additionally, route attributes may be changed
			to mount a second-level attack that is more difficult to detect.
	list policy-definition {		Some of the readable data nodes in the YANG module may be considered
	key "name";		sensitive or vulnerable in some network environments. It is thus
	description		important to control read access (e.g., via get, get-config, or
	"List of top-level policy definitions, keyed by unique		notification) to these data nodes. These are the subtrees and data
	name. These policy definitions are expected to be		nodes and their sensitivity/vulnerability:
	referenced (by name) in policy chains specified in
	import or export configuration statements.";
	leaf name {		/routing-policy/defined-sets/prefix-sets -- Knowledge of these
	type string;		data nodes can be used to ascertain which local prefixes are
	description		suspectable to a Denial-of-Service (DoS) attack.
	"Name of the top-level policy definition -- this name
	is used in references to the current policy.";
	}
	container statements {		/routing-policy/defined-sets/prefix-sets -- Knowledge of these
	description		data nodes can be used to ascertain local neighbors against whom
	"Enclosing container for policy statements.";		to mount a Denial-of-Service (DoS) attack.
	list statement {		/routing-policy/policy-definitions/policy-definition /statements/
	key "name";		-- Knowledge of these data nodes can be used to attack the local
	ordered-by user;		router with a Denial-of-Service (DoS) attack. Additionally,
	description		policies and their attendant conditions and actions should be
	"Policy statements group conditions and actions		considered proprietary and disclosure could be used to ascertain
	within a policy definition. They are evaluated in		partners, customers, and supplies. Furthermore, the policies
	the order specified (see the description of policy		themselves could represent intellectual property and disclosure
	evaluation at the top of this module.";		could diminish their corresponding business advantage.
	leaf name {		Routing policy configuration has a significant impact on network
	type string;		operations, and, as such, any related model carries potential
	description		security risks. Unauthorized access or invalid data could cause
	"Name of the policy statement.";		major disruption.
	}
	container conditions {		9. IANA Considerations
	description
	"Condition statements for the current policy
	statement.";
	leaf call-policy {		This document registers a URI in the IETF XML registry [RFC3688].
	type leafref {		Following the format in [RFC3688], the following registration is
	path "../../../../../../" +		requested to be made:
	"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.";
	}
	leaf source-protocol {		URI: urn:ietf:params:xml:ns:yang:ietf-routing-policy
	type identityref {		Registrant Contact: The IESG.
	base rt:control-plane-protocol;		XML: N/A, the requested URI is an XML namespace.
	}
	description
	"Condition to check the protocol / method used to
	install the route into the local routing table.";
	}
	uses match-interface-condition;		This document registers a YANG module in the YANG Module Names
	uses prefix-set-condition;		registry [RFC6020].
	uses neighbor-set-condition;
	uses tag-set-condition;
	uses match-route-type-condition;
	}
	container actions {		name: ietf-routing-policy
	description		namespace: urn:ietf:params:xml:ns:yang:ietf-routing-policy
	"Top-level container for policy action		prefix: rt-pol
	statements.";		reference: RFC XXXX
	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 or export level.";
	}
	description
	"Set the level for importation or
	exportation of routes.";
	}
	leaf set-preference {
	type uint16;
	description
	"Set the preference for the route.";
	}
	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.";
	}
	}
	}
	}
	}
	}
	}
	}
	CODE ENDS>
	10. Acknowledgements		10. Acknowledgements
	The routing policy module defined in this document is based on the		The routing policy module defined in this document is based on the
	OpenConfig route policy model. The authors would like to thank to		OpenConfig route policy model. The authors would like to thank to
	OpenConfig for their contributions, especially Anees Shaikh, Rob		OpenConfig for their contributions, especially Anees Shaikh, Rob
	Shakir, Kevin D'Souza, and Chris Chase.		Shakir, Kevin D'Souza, and Chris Chase.
	The authors are grateful for valuable contributions to this document		The authors are grateful for valuable contributions to this document
	and the associated models from: Ebben Aires, Luyuan Fang, Josh		and the associated models from: Ebben Aires, Luyuan Fang, Josh
	skipping to change at page 39, line 10 ¶		skipping to change at page 41, line 7 ¶
	+--rw bp:set-ext-community		+--rw bp:set-ext-community
	+--rw bp:method? enumeration		+--rw bp:method? enumeration
	+--rw bp:options?		+--rw bp:options?
	+--rw bp:inline		+--rw bp:inline
	| +--rw bp:communities* union		| +--rw bp:communities* union
	+--rw bp:reference		+--rw bp:reference
	+--rw bp:ext-community-set-ref?		+--rw bp:ext-community-set-ref?
	Appendix B. Policy examples		Appendix B. Policy examples
	Below we show an example 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 also how they can be applied. Note that the XML has		defined, and how they can be applied. Note that the XML has been
	been simplified for readability.		simplified for readability.
			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-
			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>
	<mode>ipv4</mode>		<mode>ipv4</mode>
	skipping to change at page 39, line 37 ¶		skipping to change at page 41, line 38 ¶
	<mask-length-lower>24</mask-length-lower>		<mask-length-lower>24</mask-length-lower>
	<mask-length-upper>32</mask-length-upper>		<mask-length-upper>32</mask-length-upper>
	</prefix-list>		</prefix-list>
	<prefix-list>		<prefix-list>
	<ip-prefix>198.51.100.0/24</ip-prefix>		<ip-prefix>198.51.100.0/24</ip-prefix>
	<mask-length-lower>24</mask-length-lower>		<mask-length-lower>24</mask-length-lower>
	<mask-length-upper>32</mask-length-upper>		<mask-length-upper>32</mask-length-upper>
	</prefix-list>		</prefix-list>
	</prefixes>		</prefixes>
	</prefix-set>		</prefix-set>
			<prefix-set>
			<name>prefix-set-B</name>
			<mode>ipv6</mode>
			<prefixes>
			<prefix-list>
			<ip-prefix>2001:DB8::/32</ip-prefix>
			<mask-length-lower>32</mask-length-lower>
			<mask-length-upper>64</mask-length-upper>
			</prefix-list>
			</prefixes>
			</prefix-set>
	</prefix-sets>		</prefix-sets>
	<tag-sets>		<tag-sets>
	<tag-set>		<tag-set>
	<name>cust-tag1</name>		<name>cust-tag1</name>
	<tag-value>10</tag-value>		<tag-value>10</tag-value>
	</tag-set>		</tag-set>
	</tag-sets>		</tag-sets>
	</defined-sets>		</defined-sets>
	<policy-definitions>		<policy-definitions>
	<policy-definition>		<policy-definition>
	<name>export-tagged-BGP</name>		<name>export-tagged-BGP</name>
	<statements>		<statements>
	<statement>		<statement>
	<name>term-0</name>		<name>term-0</name>
	<conditions>		<conditions>
			<match-prefix-set>
			<prefix-set>prefix-set-A</prefix-set>
			</match-prefix-set>
	<match-tag-set>		<match-tag-set>
	<tag-set>cust-tag1</tag-set>		<tag-set>cust-tag1</tag-set>
	</match-tag-set>		</match-tag-set>
	</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>
	skipping to change at page 41, line 16 ¶		skipping to change at page 43, line 41 ¶
	Yingzhen Qu		Yingzhen Qu
	Futurewei		Futurewei
	2330 Central Expressway		2330 Central Expressway
	Santa Clara CA 95050		Santa Clara CA 95050
	USA		USA
	Email: yingzhen.qu@futurewei.com		Email: yingzhen.qu@futurewei.com
	Jeff Tantsura		Jeff Tantsura
	Apstra		Juniper Networks
	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		US
	Email: acee@cisco.com		Email: acee@cisco.com
	Xufeng Liu		Xufeng Liu
	Volta Networks		Volta Networks
End of changes. 167 change blocks.
	999 lines changed or deleted		1113 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/