draft-ietf-teas-yang-rsvp-11.txt		draft-ietf-teas-yang-rsvp-12.txt
	TEAS Working Group V. Beeram		TEAS Working Group V. Beeram
	Internet-Draft T. Saad		Internet-Draft T. Saad
	Intended status: Standards Track Juniper Networks		Intended status: Standards Track Juniper Networks
	Expires: January 5, 2020 R. Gandhi		Expires: July 16, 2020 R. Gandhi
	Cisco Systems, Inc.		Cisco Systems, Inc.
	X. Liu		X. Liu
	Jabil		Jabil
	I. Bryskin		I. Bryskin
	Huawei Technologies		Huawei Technologies
	July 04, 2019		January 13, 2020
	A YANG Data Model for Resource Reservation Protocol (RSVP)		A YANG Data Model for Resource Reservation Protocol (RSVP)
	draft-ietf-teas-yang-rsvp-11		draft-ietf-teas-yang-rsvp-12
	Abstract		Abstract
	This document defines a YANG data model for the configuration and		This document defines a YANG data model for the configuration and
	management of RSVP Protocol. The model covers the building blocks of		management of RSVP Protocol. The model covers the building blocks of
	the RSVP protocol that can be augmented and used by other RSVP		the RSVP protocol that can be augmented and used by other RSVP
	extension models such as RSVP extensions to Traffic-Engineering		extension models such as RSVP extensions to Traffic-Engineering
	(RSVP-TE). The model covers the configuration, operational state,		(RSVP-TE). The model covers the configuration, operational state,
	remote procedure calls, and event notifications data.		remote procedure calls, and event notifications data.
	skipping to change at page 1, line 41 ¶		skipping to change at page 1, line 41 ¶
	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 5, 2020.		This Internet-Draft will expire on July 16, 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 25 ¶		skipping to change at page 2, line 25 ¶
	1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3		1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
	1.2. Model Tree Diagram . . . . . . . . . . . . . . . . . . . 3		1.2. Model Tree Diagram . . . . . . . . . . . . . . . . . . . 3
	1.3. Prefixes in Data Node Names . . . . . . . . . . . . . . . 3		1.3. Prefixes in Data Node Names . . . . . . . . . . . . . . . 3
	2. Model Overview . . . . . . . . . . . . . . . . . . . . . . . 3		2. Model Overview . . . . . . . . . . . . . . . . . . . . . . . 3
	2.1. Module(s) Relationship . . . . . . . . . . . . . . . . . 4		2.1. Module(s) Relationship . . . . . . . . . . . . . . . . . 4
	2.2. Design Considerations . . . . . . . . . . . . . . . . . . 4		2.2. Design Considerations . . . . . . . . . . . . . . . . . . 4
	2.3. Model Notifications . . . . . . . . . . . . . . . . . . . 5		2.3. Model Notifications . . . . . . . . . . . . . . . . . . . 5
	2.4. RSVP Base YANG Model . . . . . . . . . . . . . . . . . . 5		2.4. RSVP Base YANG Model . . . . . . . . . . . . . . . . . . 5
	2.4.1. Tree Diagram . . . . . . . . . . . . . . . . . . . . 7		2.4.1. Tree Diagram . . . . . . . . . . . . . . . . . . . . 7
	2.4.2. YANG Module . . . . . . . . . . . . . . . . . . . . . 11		2.4.2. YANG Module . . . . . . . . . . . . . . . . . . . . . 11
	2.5. RSVP Extended YANG Model . . . . . . . . . . . . . . . . 31		2.5. RSVP Extended YANG Model . . . . . . . . . . . . . . . . 32
	2.5.1. Tree Diagram . . . . . . . . . . . . . . . . . . . . 31		2.5.1. Tree Diagram . . . . . . . . . . . . . . . . . . . . 32
	2.5.2. YANG Module . . . . . . . . . . . . . . . . . . . . . 33		2.5.2. YANG Module . . . . . . . . . . . . . . . . . . . . . 34
	3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 44		3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 45
	4. Security Considerations . . . . . . . . . . . . . . . . . . . 45		4. Security Considerations . . . . . . . . . . . . . . . . . . . 46
	5. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 46		5. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 47
	6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 46		6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 47
	7. Normative References . . . . . . . . . . . . . . . . . . . . 46		7. References . . . . . . . . . . . . . . . . . . . . . . . . . 47
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 49		7.1. Normative References . . . . . . . . . . . . . . . . . . 47
			7.2. Informative References . . . . . . . . . . . . . . . . . 50
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 50
	1. Introduction		1. Introduction
	YANG [RFC6020] is a data definition language that was introduced to		YANG [RFC6020] is a data definition language that was introduced to
	define the contents of a conceptual data store that allows networked		define the contents of a conceptual data store that allows networked
	devices to be managed using NETCONF [RFC6241]. YANG is proving		devices to be managed using NETCONF [RFC6241]. YANG is proving
	relevant beyond its initial confines, as bindings to other interfaces		relevant beyond its initial confines, as bindings to other interfaces
	(e.g. ReST) and encoding other than XML (e.g. JSON) are being		(e.g. ReST) and encoding other than XML (e.g. JSON) are being
	defined. Furthermore, YANG data models can be used as the basis of		defined. Furthermore, YANG data models can be used as the basis of
	implementation for other interfaces, such as CLI and programmatic		implementation for other interfaces, such as CLI and programmatic
	skipping to change at page 5, line 20 ¶		skipping to change at page 5, line 20 ¶
	interfaces, or neighbors) are assumed to apply equally to all		interfaces, or neighbors) are assumed to apply equally to all
	elements of the list, unless overridden explicitly for a certain		elements of the list, unless overridden explicitly for a certain
	element (e.g. interface). Vendors are expected to augment the above		element (e.g. interface). Vendors are expected to augment the above
	container(s) to provide the list of inheritance command for their		container(s) to provide the list of inheritance command for their
	implementations.		implementations.
	2.3. Model Notifications		2.3. Model Notifications
	Notifications data modeling is key in any defined data model.		Notifications data modeling is key in any defined data model.
	[I-D.ietf-netconf-subscribed-notifications] and		[RFC8639] and [RFC8641] define a subscription and push mechanism for
	[I-D.ietf-netconf-yang-push] define a subscription and push mechanism		YANG datastores. This mechanism currently allows the user to:
	for YANG datastores. This mechanism currently allows the user to:
	o Subscribe notifications on a per client basis		o Subscribe notifications on a per client basis
	o Specify subtree filters or xpath filters so that only interested		o Specify subtree filters or xpath filters so that only interested
	contents will be sent.		contents will be sent.
	o Specify either periodic or on-demand notifications.		o Specify either periodic or on-demand notifications.
	2.4. RSVP Base YANG Model		2.4. RSVP Base YANG Model
	skipping to change at page 11, line 22 ¶		skipping to change at page 11, line 22 ¶
	| +--:(match-all)		| +--:(match-all)
	| | +---w all empty		| | +---w all empty
	| +--:(match-one)		| +--:(match-one)
	| +---w session-info		| +---w session-info
	| +---w (session-type)		| +---w (session-type)
	| +--:(rsvp-session-ip)		| +--:(rsvp-session-ip)
	| +---w destination leafref		| +---w destination leafref
	| +---w protocol-id uint8		| +---w protocol-id uint8
	| +---w destination-port inet:ip-address		| +---w destination-port inet:ip-address
	+---x clear-neighbor		+---x clear-neighbor
			| +---w input
			| +---w routing-protocol-instance-name leafref
			| +---w (filter-type)
			| +--:(match-all)
			| | +---w all empty
			| +--:(match-one)
			| +---w neighbor-address leafref
			+---x clear-authentication
	+---w input		+---w input
	+---w routing-protocol-instance-name leafref		+---w routing-protocol-instance-name leafref
	+---w (filter-type)		+---w (filter-type)
	+--:(match-all)		+--:(match-all)
	| +---w all empty		| +---w all empty
	+--:(match-one)		+--:(match-one-interface)
	+---w neighbor-address leafref		+---w interface? if:interface-ref
	Figure 3: RSVP model tree diagram		Figure 3: RSVP model tree diagram
	2.4.2. YANG Module		2.4.2. YANG Module
	The ietf-rsvp module imports from the following modules:		The ietf-rsvp module imports from the following modules:
	o ietf-interfaces defined in [RFC8343]		o ietf-interfaces defined in [RFC8343]
	o ietf-yang-types and ietf-inet-types defined in [RFC6991]		o ietf-yang-types and ietf-inet-types defined in [RFC6991]
	o ietf-routing defined in [RFC8349]		o ietf-routing defined in [RFC8349]
	o ietf-key-chain defined in [RFC8177]		o ietf-key-chain defined in [RFC8177]
	<CODE BEGINS> file "ietf-rsvp@2019-07-04.yang"		<CODE BEGINS> file "ietf-rsvp@2020-01-13.yang"
	module ietf-rsvp {		module ietf-rsvp {
	yang-version 1.1;		yang-version 1.1;
	namespace "urn:ietf:params:xml:ns:yang:ietf-rsvp";		namespace "urn:ietf:params:xml:ns:yang:ietf-rsvp";
	/* Replace with IANA when assigned */		/* Replace with IANA when assigned */
	prefix "rsvp";		prefix "rsvp";
	import ietf-interfaces {		import ietf-interfaces {
	prefix if;		prefix if;
	reference "RFC8343: A YANG Data Model for Interface Management";		reference "RFC8343: A YANG Data Model for Interface Management";
	}		}
	import ietf-inet-types {		import ietf-inet-types {
	prefix inet;		prefix inet;
	reference "RFC6991: Common YANG Data Types";		reference "RFC6991: Common YANG Data Types";
	}		}
	skipping to change at page 13, line 32 ¶		skipping to change at page 13, line 41 ¶
	(https://trustee.ietf.org/license-info).		(https://trustee.ietf.org/license-info).
	This version of this YANG module is part of RFC XXXX; see		This version of this YANG module is part of RFC XXXX; see
	the RFC itself for full legal notices.";		the RFC itself for full legal notices.";
	// RFC Ed.: replace XXXX with actual RFC number and remove this		// RFC Ed.: replace XXXX with actual RFC number and remove this
	// note.		// note.
	// RFC Ed.: update the date below with the date of RFC publication		// RFC Ed.: update the date below with the date of RFC publication
	// and remove this note.		// and remove this note.
	revision "2019-07-04" {		revision "2020-01-13" {
	description		description
	"A YANG Data Model for Resource Reservation Protocol";		"A YANG Data Model for Resource Reservation Protocol";
	reference		reference
	"RFCXXXX: A YANG Data Model for Resource Reservation Protocol		"RFCXXXX: A YANG Data Model for Resource Reservation Protocol
	(RSVP)";		(RSVP)";
	}		}
	identity rsvp {		identity rsvp {
	base "rt:routing-protocol";		base "rt:routing-protocol";
	description "RSVP protocol";		description "RSVP protocol";
	skipping to change at page 31, line 30 ¶		skipping to change at page 31, line 41 ¶
	"/rt:control-plane-protocol/rsvp:rsvp" +		"/rt:control-plane-protocol/rsvp:rsvp" +
	"/rsvp:neighbors/rsvp:neighbor/address";		"/rsvp:neighbors/rsvp:neighbor/address";
	}		}
	mandatory true;		mandatory true;
	description "Match specific RSVP neighbor session";		description "Match specific RSVP neighbor session";
	}		}
	}		}
	}		}
	}		}
	}		}
			rpc clear-authentication {
			description
			"Clears RSVP Security Association (SA) before the
			lifetime expires.";
			input {
			leaf routing-protocol-instance-name {
			type leafref {
			path "/rt:routing/rt:control-plane-protocols/"
			+ "rt:control-plane-protocol/rt:name";
			}
			mandatory "true";
			description
			"Name of the RSVP protocol instance whose session
			is being cleared.
			If the corresponding RSVP instance doesn't exist,
			then the operation will fail with an error-tag of
			'data-missing' and an error-app-tag of
			'routing-protocol-instance-not-found'.";
			}
			choice filter-type {
			mandatory true;
			description "Filter choice";
			case match-all {
			leaf all {
			type empty;
			mandatory true;
			description "Match all RSVP security associations";
			}
			}
			case match-one-interface {
			leaf interface {
			type if:interface-ref;
			description
			"Interface where RSVP security association(s) to be
			detected";
			}
			}
			}
			}
			}
	}		}
	<CODE ENDS>		<CODE ENDS>
	2.5. RSVP Extended YANG Model		2.5. RSVP Extended YANG Model
	The RSVP extended YANG model covers non-core RSVP feature(s). It		The RSVP extended YANG model covers non-core RSVP feature(s). It
	also covers feature(s) that are not necessarily supported by all		also covers feature(s) that are not necessarily supported by all
	vendors, and hence, can be guarded with "if-feature" checks.		vendors, and hence, can be guarded with "if-feature" checks.
	2.5.1. Tree Diagram		2.5.1. Tree Diagram
	skipping to change at page 46, line 32 ¶		skipping to change at page 47, line 32 ¶
	Raqib Jones		Raqib Jones
	Brocade		Brocade
	Email: raqib@Brocade.com		Email: raqib@Brocade.com
	Bin Wen		Bin Wen
	Comcast		Comcast
	Email: Bin_Wen@cable.comcast.com		Email: Bin_Wen@cable.comcast.com
	7. Normative References		7. References
	[I-D.ietf-netconf-subscribed-notifications]
	Voit, E., Clemm, A., Prieto, A., Nilsen-Nygaard, E., and
	A. Tripathy, "Subscription to YANG Event Notifications",
	draft-ietf-netconf-subscribed-notifications-26 (work in
	progress), May 2019.
	[I-D.ietf-netconf-yang-push]
	Clemm, A. and E. Voit, "Subscription to YANG Datastores",
	draft-ietf-netconf-yang-push-25 (work in progress), May
	2019.
	[I-D.ietf-teas-yang-rsvp-te]		7.1. Normative References
	Beeram, V., Saad, T., Gandhi, R., Liu, X., Bryskin, I.,
	and H. Shah, "A YANG Data Model for RSVP-TE Protocol",
	draft-ietf-teas-yang-rsvp-te-06 (work in progress), April
	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>.
	[RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S.		[RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S.
	Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1		Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
	Functional Specification", RFC 2205, DOI 10.17487/RFC2205,		Functional Specification", RFC 2205, DOI 10.17487/RFC2205,
	September 1997, <https://www.rfc-editor.org/info/rfc2205>.		September 1997, <https://www.rfc-editor.org/info/rfc2205>.
	skipping to change at page 49, line 14 ¶		skipping to change at page 49, line 44 ¶
	[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>.
	[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>.
			[RFC8639] Voit, E., Clemm, A., Gonzalez Prieto, A., Nilsen-Nygaard,
			E., and A. Tripathy, "Subscription to YANG Notifications",
			RFC 8639, DOI 10.17487/RFC8639, September 2019,
			<https://www.rfc-editor.org/info/rfc8639>.
			[RFC8641] Clemm, A. and E. Voit, "Subscription to YANG Notifications
			for Datastore Updates", RFC 8641, DOI 10.17487/RFC8641,
			September 2019, <https://www.rfc-editor.org/info/rfc8641>.
			7.2. Informative References
			[I-D.ietf-teas-yang-rsvp-te]
			Beeram, V., Saad, T., Gandhi, R., Liu, X., Bryskin, I.,
			and H. Shah, "A YANG Data Model for RSVP-TE Protocol",
			draft-ietf-teas-yang-rsvp-te-07 (work in progress), July
			2019.
	Authors' Addresses		Authors' Addresses
	Vishnu Pavan Beeram		Vishnu Pavan Beeram
	Juniper Networks		Juniper Networks
	Email: vbeeram@juniper.net		Email: vbeeram@juniper.net
	Tarek Saad		Tarek Saad
	Juniper Networks		Juniper Networks
End of changes. 16 change blocks.
	38 lines changed or deleted		92 lines changed or added
This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/