< draft-ietf-rtgwg-policy-model-07.txt		draft-ietf-rtgwg-policy-model-08.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 13, 2020 Apstra		Expires: July 5, 2020 Apstra
	A. Lindem		A. Lindem
	Cisco		Cisco
	X. Liu		X. Liu
	Volta Networks		Volta Networks
	September 10, 2019		January 2, 2020
	A YANG Data Model for Routing Policy Management		A YANG Data Model for Routing Policy Management
	draft-ietf-rtgwg-policy-model-07		draft-ietf-rtgwg-policy-model-08
	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 13, 2020.		This Internet-Draft will expire on July 5, 2020.
	Copyright Notice		Copyright Notice
	Copyright (c) 2019 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
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	skipping to change at page 2, line 29 ¶		skipping to change at page 2, line 29 ¶
	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. Routing protocol-specific policies . . . . . . . . . . . . . 11
	8. Security Considerations . . . . . . . . . . . . . . . . . . . 13		8. Security Considerations . . . . . . . . . . . . . . . . . . . 13
	9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13		9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
	10. YANG modules . . . . . . . . . . . . . . . . . . . . . . . . 14		10. YANG modules . . . . . . . . . . . . . . . . . . . . . . . . 14
	10.1. Routing policy model . . . . . . . . . . . . . . . . . . 14		10.1. Routing policy model . . . . . . . . . . . . . . . . . . 14
	11. Policy examples . . . . . . . . . . . . . . . . . . . . . . . 30		11. Policy examples . . . . . . . . . . . . . . . . . . . . . . . 31
	12. References . . . . . . . . . . . . . . . . . . . . . . . . . 30		12. References . . . . . . . . . . . . . . . . . . . . . . . . . 31
	12.1. Normative references . . . . . . . . . . . . . . . . . . 31		12.1. Normative references . . . . . . . . . . . . . . . . . . 31
	12.2. Informative references . . . . . . . . . . . . . . . . . 32		12.2. Informative references . . . . . . . . . . . . . . . . . 32
	Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 32		Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 32
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33
	1. Introduction		1. Introduction
	This document describes a YANG [RFC6020] [RFC7950] data model for		This document describes a YANG [RFC6020] [RFC7950] data model for
	routing policy configuration based on operational usage and best		routing policy configuration based on operational usage and best
	practices in a variety of service provider networks. The model is		practices in a variety of service provider networks. The model is
	intended to be vendor-neutral, in order to allow operators to manage		intended to be vendor-neutral, in order to allow operators to manage
	policy configuration in a consistent, intuitive way in heterogeneous		policy 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 5, line 5 ¶		skipping to change at page 5, line 5 ¶
	[RFC8340].		[RFC8340].
	2.2. Prefixes in Data Node Names		2.2. Prefixes in Data Node Names
	In this document, names of data nodes, actions, and other data model		In this document, names of data nodes, actions, and other data model
	objects are often used without a prefix, as long as it is clear from		objects are often used without a prefix, as long as it is clear from
	the context in which YANG module each name is defined. Otherwise,		the context in which YANG module each name is defined. Otherwise,
	names are prefixed using the standard prefix associated with the		names are prefixed using the standard prefix associated with the
	corresponding YANG module, as shown in Table 1.		corresponding YANG module, as shown in Table 1.
	+--------+------------------------+---------------------------------+		+-----------+------------------+------------------------------------+
	| Prefix | YANG module | Reference |		| Prefix | YANG module | Reference |
	+--------+------------------------+---------------------------------+		+-----------+------------------+------------------------------------+
	| if | ietf-interfaces | [RFC8343] |		| if | ietf-interfaces | [RFC8343] |
	| | | |		| | | |
	| rt | ietf-routing | [RFC8349] |		| rt | ietf-routing | [RFC8349] |
	| | | |		| | | |
	| yang | ietf-yang-types | [RFC6991] |		| yang | ietf-yang-types | [RFC6991] |
	| | | |		| | | |
	| inet | ietf-inet-types | [RFC6991] |		| inet | ietf-inet-types | [RFC6991] |
	| | | |		| | | |
	| if-cmn | ietf-interfaces-common | [I-D.ietf-netmod-intf-ext-yang] |		| if-ext | ietf-if- | [I-D.ietf-netmod-intf-ext-yang] |
	+--------+------------------------+---------------------------------+		| | extensions | |
			| | | |
			| if-l3-vla | ietf-if-l3-vlan | [I-D.ietf-netmod-sub-intf-vlan-mod |
			| n | | el] |
			+-----------+------------------+------------------------------------+
	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 to express policies as sets of related
	conditions and actions. This includes match sets and actions that		conditions and actions. This includes match sets and actions that
	are useful across many routing protocols.		are useful across many routing protocols.
	skipping to change at page 14, line 12 ¶		skipping to change at page 14, line 12 ¶
	YANG modules will be registered in the "YANG Module Names" registry		YANG modules will be registered in the "YANG Module Names" registry
	[RFC6020].		[RFC6020].
	10. YANG modules		10. YANG modules
	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.		sections below.
	10.1. Routing policy model		10.1. Routing policy model
	<CODE BEGINS> file "ietf-routing-policy@2019-03-06.yang"		<CODE BEGINS> file "ietf-routing-policy@2020-01-02.yang"
	module ietf-routing-policy {		module ietf-routing-policy {
	yang-version "1.1";		yang-version "1.1";
	namespace "urn:ietf:params:xml:ns:yang:ietf-routing-policy";		namespace "urn:ietf:params:xml:ns:yang:ietf-routing-policy";
	prefix rt-pol;		prefix rt-pol;
	import ietf-inet-types {		import ietf-inet-types {
	prefix "inet";		prefix "inet";
	}		}
	skipping to change at page 14, line 35 ¶		skipping to change at page 14, line 35 ¶
	}		}
	import ietf-interfaces {		import ietf-interfaces {
	prefix "if";		prefix "if";
	}		}
	import ietf-routing {		import ietf-routing {
	prefix "rt";		prefix "rt";
	}		}
	import ietf-interfaces-common {		import ietf-if-extensions {
	prefix if-cmn;		prefix if-ext;
	}		}
	import ietf-if-l3-vlan {		import ietf-if-l3-vlan {
	prefix "if-l3-vlan";		prefix "if-l3-vlan";
	}		}
	organization		organization
	"IETF RTGWG - Routing Area Working Group";		"IETF RTGWG - Routing Area Working Group";
	contact		contact
	"WG Web: <http://tools.ietf.org/wg/rtgwg/>		"WG Web: <http://tools.ietf.org/wg/rtgwg/>
	WG List: <mailto:rtgwg@ietf.org>		WG List: <mailto:rtgwg@ietf.org>
	Editor: Yingzhen Qu		Editor: Yingzhen Qu
	<mailto:yingzhen.qu@huawei.com>		<mailto:yingzhen.qu@futurewei.com>
	Jeff Tantsura		Jeff Tantsura
	<mailto:jefftant.ietf@gmail.com>		<mailto:jefftant.ietf@gmail.com>
	Acee Lindem		Acee Lindem
	<mailto:acee@cisco.com>		<mailto:acee@cisco.com>
	Xufeng Liu		Xufeng Liu
	<mailto:xufeng_liu@jabil.com>		<mailto:xufeng_liu@jabil.com>
	Anees Shaikh		Anees Shaikh
	<mailto:aashaikh@google.com>";		<mailto:aashaikh@google.com>";
	description		description
	"This module describes a YANG model for routing policy		"This module describes a YANG model for routing policy
	configuration. It is a limited subset of all of the policy		configuration. It is a limited subset of all of the policy
	configuration parameters available in the variety of vendor		configuration parameters available in the variety of vendor
	implementations, but supports widely used constructs for		implementations, but supports widely used constructs for
	managing how routes are imported, exported, and modified across		managing how routes are imported, exported, and modified across
	different routing protocols. This module is intended to be		different routing protocols. This module is intended to be
	used in conjunction with routing protocol configuration modules		used in conjunction with routing protocol configuration modules
	(e.g., BGP) defined in other models.		(e.g., BGP) defined in other models.
			Copyright (c) 2020 IETF Trust and the persons identified as
			authors of the code. All rights reserved.
			Redistribution and use in source and binary forms, with or
			without modification, is permitted pursuant to, and subject to
			the license terms contained in, the Simplified BSD License set
			forth in Section 4.c of the IETF Trust's Legal Provisions
			Relating to IETF Documents
			(https://trustee.ietf.org/license-info).
			This version of this YANG module is part of RFC XXXX
			(https://www.rfc-editor.org/info/rfcXXXX); see the RFC itself
			for full legal notices.
	Route policy expression:		Route policy expression:
	Policies are expressed as a set of top-level policy		Policies are expressed as a set of top-level policy
	definitions, each of which consists of a sequence of policy		definitions, each of which consists of a sequence of policy
	statements. Policy statements consist of simple		statements. Policy statements consist of simple
	condition-action tuples. Conditions may include mutiple match		condition-action tuples. Conditions may include mutiple match
	or comparison operations, and similarly actions may be		or comparison operations, and similarly actions may be
	multitude of changes to route attributes or a final disposition		multitude of changes to route attributes or a final disposition
	of accepting or rejecting the route.		of accepting or rejecting the route.
	skipping to change at page 16, line 24 ¶		skipping to change at page 16, line 38 ¶
	the referenced policy before returning to the calling policy		the referenced policy before returning to the calling policy
	statement and resuming evaluation. If the called policy		statement and resuming evaluation. If the called policy
	results in an accept-route (either explicit or by default),		results in an accept-route (either explicit or by default),
	then the subroutine returns an effective true value to the		then the subroutine returns an effective true value to the
	calling policy. Similarly, a reject-route action returns		calling policy. Similarly, a reject-route action returns
	false. If the subroutine returns true, the calling policy		false. If the subroutine returns true, the calling policy
	continues to evaluate the remaining conditions (using a		continues to evaluate the remaining conditions (using a
	modified route if the subroutine performed any changes to the		modified route if the subroutine performed any changes to the
	route).";		route).";
	revision "2019-03-06" {		revision "2020-01-02" {
	description		description
	"Initial revision.";		"Initial revision.";
	reference		reference
	"RFC XXXX: Routing Policy Configuration Model for Service		"RFC XXXX: Routing Policy Configuration Model for Service
	Provider Networks";		Provider Networks";
	}		}
	// typedef statements		// typedef statements
	typedef default-policy-type {		typedef default-policy-type {
	skipping to change at page 23, line 26 ¶		skipping to change at page 23, line 40 ¶
	type leafref {		type leafref {
	path "/if:interfaces/if:interface/if:name";		path "/if:interfaces/if:interface/if:name";
	}		}
	description		description
	"Reference to a base interface. If a reference to a		"Reference to a base interface. If a reference to a
	subinterface is required, this leaf must be specified		subinterface is required, this leaf must be specified
	to indicate the base interface.";		to indicate the base interface.";
	}		}
	leaf subinterface {		leaf subinterface {
	type leafref {		type leafref {
	path "/if:interfaces/if:interface/if-cmn:encapsulation"		path "/if:interfaces/if:interface/if-ext:encapsulation"
	+ "/if-l3-vlan:dot1q-vlan"		+ "/if-l3-vlan:dot1q-vlan"
	+ "/if-l3-vlan:outer-tag/if-l3-vlan:vlan-id";		+ "/if-l3-vlan:outer-tag/if-l3-vlan:vlan-id";
	}		}
	description		description
	"Reference to a subinterface -- this requires the base		"Reference to a subinterface -- this requires the base
	interface to be specified using the interface leaf in		interface to be specified using the interface leaf in
	this container. If only a reference to a base interface		this container. If only a reference to a base interface
	is requuired, this leaf should not be set.";		is requuired, this leaf should not be set.";
	}		}
	description		description
	"Container for interface match conditions";		"Container for interface match conditions";
	}		}
	}		}
	grouping prefix-set-condition {		grouping prefix-set-condition {
	description		description
	"This grouping provides prefix-set conditions";		"This grouping provides prefix-set conditions";
	container match-prefix-set {		container match-prefix-set {
	skipping to change at page 31, line 4 ¶		skipping to change at page 31, line 15 ¶
	11. Policy examples		11. Policy examples
	Below we show an example of XML-encoded configuration data using the		Below we show an example 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 also how they can be applied. Note that the XML has
	been simplified for readability.		been simplified for readability.
	<?yfile include="file:///tmp/routing-policy-example-draft.xml"?>		<?yfile include="file:///tmp/routing-policy-example-draft.xml"?>
	12. References		12. References
	12.1. Normative references		12.1. Normative references
	[I-D.ietf-netmod-intf-ext-yang]		[I-D.ietf-netmod-intf-ext-yang]
	Wilton, R., Ball, D., tsingh@juniper.net, 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",
	draft-ietf-netmod-intf-ext-yang-07 (work in progress),		draft-ietf-netmod-intf-ext-yang-08 (work in progress),
	March 2019.		November 2019.
	[I-D.ietf-netmod-sub-intf-vlan-model]		[I-D.ietf-netmod-sub-intf-vlan-model]
	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 Models", draft-		Sivaraj, "Sub-interface VLAN YANG Data Models", draft-
	ietf-netmod-sub-intf-vlan-model-05 (work in progress),		ietf-netmod-sub-intf-vlan-model-06 (work in progress),
	March 2019.		November 2019.
	[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>.
	[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,		[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
	DOI 10.17487/RFC3688, January 2004,		DOI 10.17487/RFC3688, January 2004,
	<https://www.rfc-editor.org/info/rfc3688>.		<https://www.rfc-editor.org/info/rfc3688>.
	skipping to change at page 32, line 22 ¶		skipping to change at page 32, line 34 ¶
	<https://www.rfc-editor.org/info/rfc8343>.		<https://www.rfc-editor.org/info/rfc8343>.
	[RFC8349] Lhotka, L., Lindem, A., and Y. Qu, "A YANG Data Model for		[RFC8349] Lhotka, L., Lindem, A., and Y. Qu, "A YANG Data Model for
	Routing Management (NMDA Version)", RFC 8349,		Routing Management (NMDA Version)", RFC 8349,
	DOI 10.17487/RFC8349, March 2018,		DOI 10.17487/RFC8349, March 2018,
	<https://www.rfc-editor.org/info/rfc8349>.		<https://www.rfc-editor.org/info/rfc8349>.
	12.2. Informative references		12.2. Informative references
	[I-D.ietf-idr-bgp-model]		[I-D.ietf-idr-bgp-model]
	Jethanandani, M., Patel, K., and S. Hares, "BGP YANG Model		Jethanandani, M., Patel, K., Hares, S., and J. Haas, "BGP
	for Service Provider Networks", draft-ietf-idr-bgp-		YANG Model for Service Provider Networks", draft-ietf-idr-
	model-06 (work in progress), June 2019.		bgp-model-07 (work in progress), October 2019.
	Appendix A. Acknowledgements		Appendix A. Acknowledgements
	The routing policy module defined in this draft is based on the		The routing policy module defined in this draft 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
End of changes. 20 change blocks.
	36 lines changed or deleted		54 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/