< draft-ietf-rtgwg-policy-model-14.txt		draft-ietf-rtgwg-policy-model-15.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: December 3, 2020 Apstra		Expires: December 4, 2020 Apstra
	A. Lindem		A. Lindem
	Cisco		Cisco
	X. Liu		X. Liu
	Volta Networks		Volta Networks
	June 1, 2020		June 2, 2020
	A YANG Data Model for Routing Policy Management		A YANG Data Model for Routing Policy Management
	draft-ietf-rtgwg-policy-model-14		draft-ietf-rtgwg-policy-model-15
	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 December 3, 2020.		This Internet-Draft will expire on December 4, 2020.
	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 34 ¶		skipping to change at page 2, line 34 ¶
	7. Routing protocol-specific policies . . . . . . . . . . . . . 11		7. Routing protocol-specific policies . . . . . . . . . . . . . 11
	8. Security Considerations . . . . . . . . . . . . . . . . . . . 13		8. Security Considerations . . . . . . . . . . . . . . . . . . . 13
	9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14		9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
	10. YANG module . . . . . . . . . . . . . . . . . . . . . . . . . 14		10. YANG module . . . . . . . . . . . . . . . . . . . . . . . . . 14
	10.1. Routing policy model . . . . . . . . . . . . . . . . . . 15		10.1. Routing policy model . . . . . . . . . . . . . . . . . . 15
	11. Policy examples . . . . . . . . . . . . . . . . . . . . . . . 36		11. Policy examples . . . . . . . . . . . . . . . . . . . . . . . 36
	12. References . . . . . . . . . . . . . . . . . . . . . . . . . 37		12. References . . . . . . . . . . . . . . . . . . . . . . . . . 37
	12.1. Normative references . . . . . . . . . . . . . . . . . . 37		12.1. Normative references . . . . . . . . . . . . . . . . . . 37
	12.2. Informative references . . . . . . . . . . . . . . . . . 39		12.2. Informative references . . . . . . . . . . . . . . . . . 39
	Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 39		Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 39
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 40		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 39
	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 10, line 8 ¶		skipping to change at page 10, line 8 ¶
	Note that the called policy may itself call other policies (subject		Note that the called policy may itself call other policies (subject
	to implementation limitations). The model does not prescribe a		to implementation limitations). The model does not prescribe a
	nesting depth because this varies among implementations. For		nesting depth because this varies among implementations. For
	example, some major implementation may only support a single level of		example, some major 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) should be		policies nested beyond a small number of levels (e.g., 2-3) should be
	discouraged.		discouraged. Also, implementations should have validation to assure
			that there is no recursion amongst nested routing policies.
	5. Policy evaluation		5. Policy evaluation
	Evaluation of each policy definition proceeds by evaluating its		Evaluation of each policy definition proceeds by evaluating its
	corresponding individual policy statements in order. When all the		corresponding individual policy statements in order. When all the
	condition statements in a policy statement are satisfied, 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 definitions in		current policy definition stops, and no further policy definitions in
	the chain are evaluated.		the chain are evaluated.
	skipping to change at page 15, line 7 ¶		skipping to change at page 15, line 7 ¶
	10. YANG module		10. 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 the draft.		elsewhere in the draft.
	10.1. Routing policy model		10.1. Routing policy model
	<CODE BEGINS> file "ietf-routing-policy@2020-06-01.yang"		<CODE BEGINS> file "ietf-routing-policy@2020-06-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";
	reference "RFC 6991: Common YANG Data Types";		reference "RFC 6991: Common YANG Data Types";
	skipping to change at page 18, line 5 ¶		skipping to change at page 18, line 5 ¶
	The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL		The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL
	NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT		NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT
	RECOMMENDED', 'MAY', and 'OPTIONAL' in this document are to be		RECOMMENDED', 'MAY', and 'OPTIONAL' in this document are to be
	interpreted as described in BCP 14 (RFC 2119) (RFC 8174) when,		interpreted as described in BCP 14 (RFC 2119) (RFC 8174) when,
	and only when, they appear in all capitals, as shown here.		and only when, they appear in all capitals, as shown here.
	This version of this YANG module is part of RFC XXXX;		This version of this YANG module is part of RFC XXXX;
	see the RFC itself for full legal notices.";		see the RFC itself for full legal notices.";
	revision "2020-06-01" {		revision "2020-06-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";
	}		}
	/* Identities */		/* Identities */
	identity metric-type {		identity metric-type {
	skipping to change at page 25, line 4 ¶		skipping to change at page 25, line 4 ¶
	grouping prefix {		grouping prefix {
	description		description
	"Configuration data for a prefix definition.";		"Configuration data for a prefix definition.";
	leaf ip-prefix {		leaf ip-prefix {
	type inet:ip-prefix;		type inet:ip-prefix;
	mandatory true;		mandatory true;
	description		description
	"The IP prefix represented as an IPv6 or IPv4 network		"The IP prefix represented as an IPv6 or IPv4 network
	number followed prefix length with an intervening slash		number followed prefix length with an intervening slash
	character a delimiter -- while the prefix may be either		character a delimiter. All members of the prefix set
	IPv4 or IPv6, most implementations require all members		should be of the same address family as the prefix-set
	of the prefix set to be the same address family. Mixing		mode.";
	address types in the same prefix set is likely to cause
	an error.";
	}		}
	leaf mask-length-lower {		leaf mask-length-lower {
	type uint8;		type uint8;
	description		description
	"Mask length range lower bound.";		"Mask length range lower bound.";
	}		}
	leaf mask-length-upper {		leaf mask-length-upper {
	type uint8 {		type uint8 {
	range "1..128";		range "1..128";
	skipping to change at page 30, line 43 ¶		skipping to change at page 30, line 41 ¶
	container defined-sets {		container defined-sets {
	description		description
	"Predefined sets of attributes used in policy match		"Predefined sets of attributes used in policy match
	statements.";		statements.";
	container prefix-sets {		container prefix-sets {
	description		description
	"Data definitions for a list of IPv4 or IPv6		"Data definitions for a list of IPv4 or IPv6
	prefixes which are matched as part of a policy.";		prefixes which are matched as part of a policy.";
	list prefix-set {		list prefix-set {
	key "name";		key "name mode";
	description		description
	"List of the defined prefix sets";		"List of the defined prefix sets";
	leaf name {		leaf name {
	type string;		type string;
	description		description
	"Name of the prefix set -- this is used as a label to		"Name of the prefix set -- this is used as a label to
	reference the set in match conditions.";		reference the set in match conditions.";
	}		}
	leaf mode {		leaf mode {
	type enumeration {		type enumeration {
	enum ipv4 {		enum ipv4 {
	description		description
	"Prefix set contains IPv4 prefixes only.";		"Prefix set contains IPv4 prefixes only.";
	}		}
	enum ipv6 {		enum ipv6 {
	description		description
	"Prefix set contains IPv6 prefixes only.";		"Prefix set contains IPv6 prefixes only.";
	}		}
	enum mixed {
	description
	"Prefix set contains mixed IPv4 and IPv6
	prefixes.";
	}
	}		}
	description		description
	"Indicates the mode of the prefix set, in terms of		"Indicates the mode of the prefix set, in terms of
	which address families (IPv4, IPv6, or both) are		which address families (IPv4, IPv6, or both) are
	present. The mode provides a hint, but the device		present. The mode provides a hint, but the device
	must validate that all prefixes are of the indicated		must validate that all prefixes are of the indicated
	type, and is expected to reject the configuration if		type, and is expected to reject the configuration if
	there is a discrepancy. The MIXED mode may not be		there is a discrepancy.";
	supported on devices that require prefix sets to be
	of only one address family.";
	}		}
	container prefixes {		container prefixes {
	description		description
	"Container for the list of prefixes in a policy		"Container for the list of prefixes in a policy
	prefix list.";		prefix list.";
	list prefix-list {		list prefix-list {
	key "ip-prefix mask-length-lower mask-length-upper";		key "ip-prefix mask-length-lower mask-length-upper";
	description		description
End of changes. 13 change blocks.
	23 lines changed or deleted		14 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/