< draft-ietf-rtgwg-policy-model-21.txt		draft-ietf-rtgwg-policy-model-22.txt >
	RTGWG Y. Qu		RTGWG Y. Qu
	Internet-Draft Futurewei		Internet-Draft Futurewei
	Intended status: Standards Track J. Tantsura		Intended status: Standards Track J. Tantsura
	Expires: March 7, 2021 Apstra		Expires: March 19, 2021 Apstra
	A. Lindem		A. Lindem
	Cisco		Cisco
	X. Liu		X. Liu
	Volta Networks		Volta Networks
	September 3, 2020		September 15, 2020
	A YANG Data Model for Routing Policy Management		A YANG Data Model for Routing Policy Management
	draft-ietf-rtgwg-policy-model-21		draft-ietf-rtgwg-policy-model-22
	Abstract		Abstract
	This document defines a YANG data model for configuring and managing		This document defines a YANG data model for configuring and managing
	routing policies in a vendor-neutral way and based on actual		routing policies in a vendor-neutral way and based on actual
	operational practice. The model provides a generic policy framework		operational practice. The model provides a generic policy framework
	which can be augmented with protocol-specific policy configuration.		which can be augmented with protocol-specific policy configuration.
	Status of This Memo		Status of This Memo
	skipping to change at page 1, line 38 ¶		skipping to change at page 1, line 38 ¶
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at https://datatracker.ietf.org/drafts/current/.		Drafts is at https://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on March 7, 2021.		This Internet-Draft will expire on March 19, 2021.
	Copyright Notice		Copyright Notice
	Copyright (c) 2020 IETF Trust and the persons identified as the		Copyright (c) 2020 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(https://trustee.ietf.org/license-info) in effect on the date of		(https://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	skipping to change at page 2, line 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 . . . . . . . . . . . . . . . 4		2.2. Prefixes in Data Node Names . . . . . . . . . . . . . . . 4
	3. Model overview . . . . . . . . . . . . . . . . . . . . . . . 5		3. Model overview . . . . . . . . . . . . . . . . . . . . . . . 5
	4. Route policy expression . . . . . . . . . . . . . . . . . . . 5		4. Route policy expression . . . . . . . . . . . . . . . . . . . 5
	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. Routing protocol-specific policies . . . . . . . . . . . . . 11		7. Security Considerations . . . . . . . . . . . . . . . . . . . 11
	8. Security Considerations . . . . . . . . . . . . . . . . . . . 13		8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
	9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14		9. YANG module . . . . . . . . . . . . . . . . . . . . . . . . . 12
	10. YANG module . . . . . . . . . . . . . . . . . . . . . . . . . 15		9.1. Routing policy model . . . . . . . . . . . . . . . . . . 12
	10.1. Routing policy model . . . . . . . . . . . . . . . . . . 15		10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 33
	11. Policy examples . . . . . . . . . . . . . . . . . . . . . . . 36		11. References . . . . . . . . . . . . . . . . . . . . . . . . . 34
	12. References . . . . . . . . . . . . . . . . . . . . . . . . . 38		11.1. Normative references . . . . . . . . . . . . . . . . . . 34
	12.1. Normative references . . . . . . . . . . . . . . . . . . 38		11.2. Informative references . . . . . . . . . . . . . . . . . 36
	12.2. Informative references . . . . . . . . . . . . . . . . . 40		Appendix A. Routing protocol-specific policies . . . . . . . . . 36
	Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 40		Appendix B. Policy examples . . . . . . . . . . . . . . . . . . 39
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 41		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 41
	1. Introduction		1. Introduction
	This document describes a YANG [RFC7950] data model for routing		This document describes a YANG [RFC7950] data model for routing
	policy configuration based on operational usage and best practices in		policy configuration based on operational usage and best practices in
	a variety of service provider networks. The model is intended to be		a variety of service provider networks. The model is intended to be
	vendor-neutral, in order to allow operators to manage policy		vendor-neutral, in order to allow operators to manage policy
	configuration in a consistent, intuitive way in heterogeneous		configuration in a consistent, intuitive way in heterogeneous
	environments with routers supplied by multiple vendors.		environments with routers supplied by multiple vendors.
	skipping to change at page 11, line 14 ¶		skipping to change at page 11, line 14 ¶
	+--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. Routing protocol-specific policies		7. Security Considerations
	Routing models that require the ability to apply routing policy may
	augment the routing policy model with protocol or other specific
	policy configuration. The routing policy model assumes that
	additional defined sets, conditions, and actions may all be added by
	other models.
	The example below provides an illustration of how another data model
	can augment parts of this routing policy data model. It uses
	specific examples from draft-ietf-idr-bgp-model-09 to show in a
	concrete manner how the different pieces fit together. This example
	is not normative with respect to [I-D.ietf-idr-bgp-model]. The model
	similarly augments BGP-specific conditions and actions in the
	corresponding sections of the routing policy model.
	module: ietf-routing-policy
	+--rw routing-policy
	+--rw defined-sets
	| +--rw prefix-sets
	| | +--rw prefix-set* [name]
	| | +--rw name string
	| | +--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 bp:bgp-defined-sets
	| +--rw bp:community-sets
	| | +--rw bp:community-set* [name]
	| | +--rw bp:name string
	| | +--rw bp:member* union
	| +--rw bp:ext-community-sets
	| | +--rw bp:ext-community-set* [name]
	| | +--rw bp:name string
	| | +--rw bp:member* union
	| +--rw bp:as-path-sets
	| +--rw bp:as-path-set* [name]
	| +--rw bp:name string
	| +--rw bp:member* string
	+--rw policy-definitions
	+--rw policy-definition* [name]
	+--rw name string
	+--rw statements
	+--rw statement* [name]
	+--rw name string
	+--rw conditions
	| +--rw call-policy?
	| +--rw source-protocol? identityref
	| +--rw match-interface
	| | +--rw interface?
	| | +--rw subinterface?
	| +--rw match-prefix-set
	| | +--rw prefix-set? prefix-set/name
	| | +--rw match-set-options? match-set-options-type
	| +--rw match-neighbor-set
	| | +--rw neighbor-set?
	| +--rw match-tag-set
	| | +--rw tag-set?
	| | +--rw match-set-options? match-set-options-type
	| +--rw match-route-type* identityref
	| +--rw bp:bgp-conditions
	| +--rw bp:med-eq? uint32
	| +--rw bp:origin-eq? bt:bgp-origin-attr-type
	| +--rw bp:next-hop-in* inet:ip-address-no-zone
	| +--rw bp:afi-safi-in* identityref
	| +--rw bp:local-pref-eq? uint32
	| +--rw bp:route-type? enumeration
	| +--rw bp:community-count
	| +--rw bp:as-path-length
	| +--rw bp:match-community-set
	| | +--rw bp:community-set?
	| | +--rw bp:match-set-options?
	| +--rw bp:match-ext-community-set
	| | +--rw bp:ext-community-set?
	| | +--rw bp:match-set-options?
	| +--rw bp:match-as-path-set
	| +--rw bp:as-path-set?
	| +--rw bp:match-set-options?
	+--rw actions
	+--rw policy-result? policy-result-type
	+--rw set-metric
	| +--rw metric-modification?
	| +--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
	+--rw bp:bgp-actions
	+--rw bp:set-route-origin?bt:bgp-origin-attr-type
	+--rw bp:set-local-pref? uint32
	+--rw bp:set-next-hop? bgp-next-hop-type
	+--rw bp:set-med? bgp-set-med-type
	+--rw bp:set-as-path-prepend
	| +--rw bp:repeat-n? uint8
	+--rw bp:set-community
	| +--rw bp:method? enumeration
	| +--rw bp:options?
	| +--rw bp:inline
	| | +--rw bp:communities* union
	| +--rw bp:reference
	| +--rw bp:community-set-ref?
	+--rw bp:set-ext-community
	+--rw bp:method? enumeration
	+--rw bp:options?
	+--rw bp:inline
	| +--rw bp:communities* union
	+--rw bp:reference
	+--rw bp:ext-community-set-ref?
	8. Security Considerations
	The YANG modules specified in this document define a schema for data		The YANG modules specified in this document define a schema for data
	that is designed to be accessed via network management protocols such		that is designed to be accessed via network management protocols such
	as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer		as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer
	is the secure transport layer, and the mandatory-to-implement secure		is the secure transport layer, and the mandatory-to-implement secure
	transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer		transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer
	is HTTPS, and the mandatory-to-implement secure transport is TLS		is HTTPS, and the mandatory-to-implement secure transport is TLS
	[RFC8446].		[RFC8446].
	The NETCONF Access Control Model (NACM) [RFC8341] provides the means		The NETCONF Access Control Model (NACM) [RFC8341] provides the means
	skipping to change at page 14, line 33 ¶		skipping to change at page 12, line 7 ¶
	/routing-policy/policy-definitions		/routing-policy/policy-definitions
	Unauthorized access to any data node of these subtrees can disclose		Unauthorized access to any data node of these subtrees can disclose
	the operational state information of routing policies on this device.		the operational state information of routing policies on this device.
	Routing policy configuration has a significant impact on network		Routing policy configuration has a significant impact on network
	operations, and, as such, any related model carries potential		operations, and, as such, any related model carries potential
	security risks. Unauthorized access or invalid data could cause		security risks. Unauthorized access or invalid data could cause
	major disruption.		major disruption.
	9. IANA Considerations		8. IANA Considerations
	This document registers a URI in the IETF XML registry [RFC3688].		This document registers a URI in the IETF XML registry [RFC3688].
	Following the format in [RFC3688], the following registration is		Following the format in [RFC3688], the following registration is
	requested to be made:		requested to be made:
	URI: urn:ietf:params:xml:ns:yang:ietf-routing-policy		URI: urn:ietf:params:xml:ns:yang:ietf-routing-policy
	Registrant Contact: The IESG.		Registrant Contact: The IESG.
	XML: N/A, the requested URI is an XML namespace.		XML: N/A, the requested URI is an XML namespace.
	This document registers a YANG module in the YANG Module Names		This document registers a YANG module in the YANG Module Names
	registry [RFC6020].		registry [RFC6020].
	name: ietf-routing-policy		name: ietf-routing-policy
	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
	reference: RFC XXXX		reference: RFC XXXX
	10. YANG module		9. YANG module
	The routing policy model is described by the YANG modules in the		The routing policy model is described by the YANG modules in the
	sections below. [RFC2328], [RFC3101], [RFC5130], and [RFC5302] are		sections below. [RFC2328], [RFC3101], [RFC5130], and [RFC5302] are
	referenced here since they are referenced in the YANG model but not		referenced here since they are referenced in the YANG model but not
	elsewhere in this document.		elsewhere in this document.
	10.1. Routing policy model		9.1. Routing policy model
	<CODE BEGINS> file "ietf-routing-policy@2020-08-17.yang"		<CODE BEGINS> file "ietf-routing-policy@2020-08-17.yang"
	module ietf-routing-policy {		module ietf-routing-policy {
	yang-version "1.1";		yang-version "1.1";
	namespace "urn:ietf:params:xml:ns:yang:ietf-routing-policy";		namespace "urn:ietf:params:xml:ns:yang:ietf-routing-policy";
	prefix rt-pol;		prefix rt-pol;
	import ietf-inet-types {		import ietf-inet-types {
	skipping to change at page 36, line 20 ¶		skipping to change at page 33, line 42 ¶
	}		}
	}		}
	}		}
	}		}
	}		}
	}		}
	}		}
	}		}
	CODE ENDS>		CODE ENDS>
	11. Policy examples		10. Acknowledgements
	Below we show an example of XML-encoded configuration data using the
	routing policy and BGP models to illustrate both how policies are
	defined, and also how they can be applied. Note that the XML has
	been simplified for readability.
	<config xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
	<routing-policy
	xmlns="urn:ietf:params:xml:ns:yang:ietf-routing-policy">
	<defined-sets>
	<prefix-sets>
	<prefix-set>
	<name>prefix-set-A</name>
	<mode>ipv4</mode>
	<prefixes>
	<prefix-list>
	<ip-prefix>192.0.2.0/24</ip-prefix>
	<mask-length-lower>24</mask-length-lower>
	<mask-length-upper>32</mask-length-upper>
	</prefix-list>
	<prefix-list>
	<ip-prefix>198.51.100.0/24</ip-prefix>
	<mask-length-lower>24</mask-length-lower>
	<mask-length-upper>32</mask-length-upper>
	</prefix-list>
	</prefixes>
	</prefix-set>
	</prefix-sets>
	<tag-sets>
	<tag-set>
	<name>cust-tag1</name>
	<tag-value>10</tag-value>
	</tag-set>
	</tag-sets>
	</defined-sets>
	<policy-definitions>
	<policy-definition>
	<name>export-tagged-BGP</name>
	<statements>
	<statement>
	<name>term-0</name>
	<conditions>
	<match-tag-set>
	<tag-set>cust-tag1</tag-set>
	</match-tag-set>
	</conditions>
	<actions>
	<policy-result>accept-route</policy-result>
	</actions>
	</statement>
	</statements>
	</policy-definition>
	</policy-definitions>
	</routing-policy>		The routing policy module defined in this document is based on the
	</config>		OpenConfig route policy model. The authors would like to thank to
			OpenConfig for their contributions, especially Anees Shaikh, Rob
			Shakir, Kevin D'Souza, and Chris Chase.
	In the following example, all routes in the RIB that have been		The authors are grateful for valuable contributions to this document
	learned from OSPF advertisements corresponding to OSPF intra-area and		and the associated models from: Ebben Aires, Luyuan Fang, Josh
	inter-area route types should get advertised into ISIS level-2		George, Stephane Litkowski, Ina Minei, Carl Moberg, Eric Osborne,
	advertisements.		Steve Padgett, Juergen Schoenwaelder, Jim Uttaro, Russ White, and
			John Heasley.
	<config xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">		Thanks to Mahesh Jethanandani, John Scudder, Chris Bower and Tom
	<routing-policy		Petch for their reviews and comments.
	xmlns="urn:ietf:params:xml:ns:yang:ietf-routing-policy">
	<policy-definitions>
	<policy-definition>
	<name>export-all-OSPF-prefixes-into-ISIS-level-2</name>
	<statements>
	<statement>
	<name>term-0</name>
	<conditions>
	<match-route-type>ospf-internal-type</match-route-type>
	</conditions>
	<actions>
	<set-route-level>
	<route-level>isis-level-2</route-level>
	</set-route-level>
	<policy-result>accept-route</policy-result>
	</actions>
	</statement>
	</statements>
	</policy-definition>
	</policy-definitions>
	</routing-policy>
	</config>
	12. References		11. References
	12.1. Normative references		11.1. Normative references
	[INTF-EXT-YANG]		[INTF-EXT-YANG]
	Wilton, R., Ball, D., tapsingh@cisco.com, t., and S.		Wilton, R., Ball, D., tapsingh@cisco.com, t., and S.
	Sivaraj,, "Common Interface Extension YANG Data Models",		Sivaraj,, "Common Interface Extension YANG Data Models",
	2019, <https://datatracker.ietf.org/doc/draft-ietf-netmod-		2019, <https://datatracker.ietf.org/doc/
	intf-ext-yang/>.		draft-ietf-netmod-intf-ext-yang/>.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119,		Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997,		DOI 10.17487/RFC2119, March 1997,
	<https://www.rfc-editor.org/info/rfc2119>.		<https://www.rfc-editor.org/info/rfc2119>.
	[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328,		[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328,
	DOI 10.17487/RFC2328, April 1998,		DOI 10.17487/RFC2328, April 1998,
	<https://www.rfc-editor.org/info/rfc2328>.		<https://www.rfc-editor.org/info/rfc2328>.
	skipping to change at page 40, line 35 ¶		skipping to change at page 36, line 17 ¶
	DOI 10.17487/RFC8349, March 2018,		DOI 10.17487/RFC8349, March 2018,
	<https://www.rfc-editor.org/info/rfc8349>.		<https://www.rfc-editor.org/info/rfc8349>.
	[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol		[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
	Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,		Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
	<https://www.rfc-editor.org/info/rfc8446>.		<https://www.rfc-editor.org/info/rfc8446>.
	[SUB-INTF-VLAN-YANG]		[SUB-INTF-VLAN-YANG]
	Wilton, R., Ball, D., tapsingh@cisco.com, t., and S.		Wilton, R., Ball, D., tapsingh@cisco.com, t., and S.
	Sivaraj, "Sub-interface VLAN YANG Data Model", 2019,		Sivaraj, "Sub-interface VLAN YANG Data Model", 2019,
	<https://datatracker.ietf.org/doc/draft-ietf-netmod-sub-		<https://datatracker.ietf.org/doc/
	intf-vlan-model/>.		draft-ietf-netmod-sub-intf-vlan-model/>.
	12.2. Informative references		11.2. Informative references
	[I-D.ietf-idr-bgp-model]		[I-D.ietf-idr-bgp-model]
	Jethanandani, M., Patel, K., Hares, S., and J. Haas, "BGP		Jethanandani, M., Patel, K., Hares, S., and J. Haas, "BGP
	YANG Model for Service Provider Networks", draft-ietf-idr-		YANG Model for Service Provider Networks", draft-ietf-idr-
	bgp-model-09 (work in progress), June 2020.		bgp-model-09 (work in progress), June 2020.
	Appendix A. Acknowledgements		Appendix A. Routing protocol-specific policies
	The routing policy module defined in this document is based on the		Routing models that require the ability to apply routing policy may
	OpenConfig route policy model. The authors would like to thank to		augment the routing policy model with protocol or other specific
	OpenConfig for their contributions, especially Anees Shaikh, Rob		policy configuration. The routing policy model assumes that
	Shakir, Kevin D'Souza, and Chris Chase.		additional defined sets, conditions, and actions may all be added by
			other models.
	The authors are grateful for valuable contributions to this document		The example below provides an illustration of how another data model
	and the associated models from: Ebben Aires, Luyuan Fang, Josh		can augment parts of this routing policy data model. It uses
	George, Stephane Litkowski, Ina Minei, Carl Moberg, Eric Osborne,		specific examples from draft-ietf-idr-bgp-model-09 to show in a
	Steve Padgett, Juergen Schoenwaelder, Jim Uttaro, Russ White, and		concrete manner how the different pieces fit together. This example
	John Heasley.		is not normative with respect to [I-D.ietf-idr-bgp-model]. The model
			similarly augments BGP-specific conditions and actions in the
			corresponding sections of the routing policy model. In the example
			below, the XPath prefix "bp:" specifies import from the ietf-bgp-
			policy sub-module and the XPath prefix "bt:" specifies import from
			the ietf-bgp-types sub-module [I-D.ietf-idr-bgp-model].
	Thanks to Mahesh Jethanandani, John Scudder, Chris Bower and Tom		module: ietf-routing-policy
	Petch for their reviews and comments.		+--rw routing-policy
			+--rw defined-sets
			| +--rw prefix-sets
			| | +--rw prefix-set* [name]
			| | +--rw name string
			| | +--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 bp:bgp-defined-sets
			| +--rw bp:community-sets
			| | +--rw bp:community-set* [name]
			| | +--rw bp:name string
			| | +--rw bp:member* union
			| +--rw bp:ext-community-sets
			| | +--rw bp:ext-community-set* [name]
			| | +--rw bp:name string
			| | +--rw bp:member* union
			| +--rw bp:as-path-sets
			| +--rw bp:as-path-set* [name]
			| +--rw bp:name string
			| +--rw bp:member* string
			+--rw policy-definitions
			+--rw policy-definition* [name]
			+--rw name string
			+--rw statements
			+--rw statement* [name]
			+--rw name string
			+--rw conditions
			| +--rw call-policy?
			| +--rw source-protocol? identityref
			| +--rw match-interface
			| | +--rw interface?
			| | +--rw subinterface?
			| +--rw match-prefix-set
			| | +--rw prefix-set? prefix-set/name
			| | +--rw match-set-options? match-set-options-type
			| +--rw match-neighbor-set
			| | +--rw neighbor-set?
			| +--rw match-tag-set
			| | +--rw tag-set?
			| | +--rw match-set-options? match-set-options-type
			| +--rw match-route-type* identityref
			| +--rw bp:bgp-conditions
			| +--rw bp:med-eq? uint32
			| +--rw bp:origin-eq? bt:bgp-origin-attr-type
			| +--rw bp:next-hop-in* inet:ip-address-no-zone
			| +--rw bp:afi-safi-in* identityref
			| +--rw bp:local-pref-eq? uint32
			| +--rw bp:route-type? enumeration
			| +--rw bp:community-count
			| +--rw bp:as-path-length
			| +--rw bp:match-community-set
			| | +--rw bp:community-set?
			| | +--rw bp:match-set-options?
			| +--rw bp:match-ext-community-set
			| | +--rw bp:ext-community-set?
			| | +--rw bp:match-set-options?
			| +--rw bp:match-as-path-set
			| +--rw bp:as-path-set?
			| +--rw bp:match-set-options?
			+--rw actions
			+--rw policy-result? policy-result-type
			+--rw set-metric
			| +--rw metric-modification?
			| +--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
			+--rw bp:bgp-actions
			+--rw bp:set-route-origin?bt:bgp-origin-attr-type
			+--rw bp:set-local-pref? uint32
			+--rw bp:set-next-hop? bgp-next-hop-type
			+--rw bp:set-med? bgp-set-med-type
			+--rw bp:set-as-path-prepend
			| +--rw bp:repeat-n? uint8
			+--rw bp:set-community
			| +--rw bp:method? enumeration
			| +--rw bp:options?
			| +--rw bp:inline
			| | +--rw bp:communities* union
			| +--rw bp:reference
			| +--rw bp:community-set-ref?
			+--rw bp:set-ext-community
			+--rw bp:method? enumeration
			+--rw bp:options?
			+--rw bp:inline
			| +--rw bp:communities* union
			+--rw bp:reference
			+--rw bp:ext-community-set-ref?
			Appendix B. Policy examples
			Below we show an example of XML-encoded configuration data using the
			routing policy and BGP models to illustrate both how policies are
			defined, and also how they can be applied. Note that the XML has
			been simplified for readability.
			<config xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
			<routing-policy
			xmlns="urn:ietf:params:xml:ns:yang:ietf-routing-policy">
			<defined-sets>
			<prefix-sets>
			<prefix-set>
			<name>prefix-set-A</name>
			<mode>ipv4</mode>
			<prefixes>
			<prefix-list>
			<ip-prefix>192.0.2.0/24</ip-prefix>
			<mask-length-lower>24</mask-length-lower>
			<mask-length-upper>32</mask-length-upper>
			</prefix-list>
			<prefix-list>
			<ip-prefix>198.51.100.0/24</ip-prefix>
			<mask-length-lower>24</mask-length-lower>
			<mask-length-upper>32</mask-length-upper>
			</prefix-list>
			</prefixes>
			</prefix-set>
			</prefix-sets>
			<tag-sets>
			<tag-set>
			<name>cust-tag1</name>
			<tag-value>10</tag-value>
			</tag-set>
			</tag-sets>
			</defined-sets>
			<policy-definitions>
			<policy-definition>
			<name>export-tagged-BGP</name>
			<statements>
			<statement>
			<name>term-0</name>
			<conditions>
			<match-tag-set>
			<tag-set>cust-tag1</tag-set>
			</match-tag-set>
			</conditions>
			<actions>
			<policy-result>accept-route</policy-result>
			</actions>
			</statement>
			</statements>
			</policy-definition>
			</policy-definitions>
			</routing-policy>
			</config>
			In the following example, all routes in the RIB that have been
			learned from OSPF advertisements corresponding to OSPF intra-area and
			inter-area route types should get advertised into ISIS level-2
			advertisements.
			<config xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
			<routing-policy
			xmlns="urn:ietf:params:xml:ns:yang:ietf-routing-policy">
			<policy-definitions>
			<policy-definition>
			<name>export-all-OSPF-prefixes-into-ISIS-level-2</name>
			<statements>
			<statement>
			<name>term-0</name>
			<conditions>
			<match-route-type>ospf-internal-type</match-route-type>
			</conditions>
			<actions>
			<set-route-level>
			<route-level>isis-level-2</route-level>
			</set-route-level>
			<policy-result>accept-route</policy-result>
			</actions>
			</statement>
			</statements>
			</policy-definition>
			</policy-definitions>
			</routing-policy>
			</config>
	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		USA
	Email: yingzhen.qu@futurewei.com		Email: yingzhen.qu@futurewei.com
End of changes. 22 change blocks.
	246 lines changed or deleted		249 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/