< draft-ietf-rtgwg-policy-model-17.txt		draft-ietf-rtgwg-policy-model-18.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: January 6, 2021 Apstra		Expires: January 14, 2021 Apstra
	A. Lindem		A. Lindem
	Cisco		Cisco
	X. Liu		X. Liu
	Volta Networks		Volta Networks
	July 5, 2020		July 13, 2020
	A YANG Data Model for Routing Policy Management		A YANG Data Model for Routing Policy Management
	draft-ietf-rtgwg-policy-model-17		draft-ietf-rtgwg-policy-model-18
	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 January 6, 2021.		This Internet-Draft will expire on January 14, 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 15, line 14 ¶		skipping to change at page 15, line 14 ¶
	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 this document.		elsewhere in this document.
	10.1. Routing policy model		10.1. Routing policy model
	<CODE BEGINS> file "ietf-routing-policy@2020-07-05.yang"		<CODE BEGINS> file "ietf-routing-policy@2020-07-13.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 12 ¶		skipping to change at page 18, line 12 ¶
	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-07-05" {		revision "2020-07-13" {
	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 31, line 38 ¶		skipping to change at page 31, line 38 ¶
	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.";		there is a discrepancy.";
	}		}
	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. 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
			outcome and is is left to the implementation. A
			given prefix-set condition is statisfied if the
			input prefix matches any of the prefixes in the
			prefix-set.";
	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
	"List of prefixes in the prefix set.";		"List of prefixes in the prefix set.";
	uses prefix;		uses prefix;
	}		}
	}		}
	}		}
	}		}
	container neighbor-sets {		container neighbor-sets {
	description		description
	"Data definition for a list of IPv4 or IPv6		"Data definition for a list of IPv4 or IPv6
	neighbors which can be matched in a routing policy.";		neighbors which can be matched in a routing policy.";
	skipping to change at page 36, line 4 ¶		skipping to change at page 36, line 10 ¶
	}		}
	leaf set-tag {		leaf set-tag {
	type tag-type;		type tag-type;
	description		description
	"Set the tag for the route.";		"Set the tag for the route.";
	}		}
	leaf set-application-tag {		leaf set-application-tag {
	type tag-type;		type tag-type;
	description		description
	"Set the application tag for the route.";		"Set the application tag for the route.";
	}		}
	}		}
	}		}
	}		}
	}		}
	}		}
	}		}
	}		}
	<CODE ENDS>
			CODE ENDS>
	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.
	<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
	skipping to change at page 38, line 37 ¶		skipping to change at page 38, line 37 ¶
	</routing-policy>		</routing-policy>
	</config>		</config>
	12. References		12. References
	12.1. Normative references		12.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 40, line 35 ¶
	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		12.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. Acknowledgements
End of changes. 12 change blocks.
	13 lines changed or deleted		20 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/