< draft-ietf-netconf-distributed-notif-01.txt		draft-ietf-netconf-distributed-notif-02.txt >
	NETCONF T. Zhou		NETCONF T. Zhou
	Internet-Draft G. Zheng		Internet-Draft G. Zheng
	Intended status: Standards Track Huawei		Intended status: Standards Track Huawei
	Expires: May 6, 2021 E. Voit		Expires: November 7, 2021 E. Voit
	Cisco Systems		Cisco Systems
	T. Graf		T. Graf
	Swisscom		Swisscom
	P. Francois		P. Francois
	INSA-Lyon		INSA-Lyon
	November 02, 2020		May 06, 2021
	Subscription to Distributed Notifications		Subscription to Distributed Notifications
	draft-ietf-netconf-distributed-notif-01		draft-ietf-netconf-distributed-notif-02
	Abstract		Abstract
	This documents describes extensions to the YANG notifications		This document describes extensions to the YANG notifications
	subscription to allow metrics being published directly from		subscription to allow metrics being published directly from
	processors on line cards to target receivers, while subscription is		processors on line cards to target receivers, while subscription is
	still maintained at the route processor in a distributed forwarding		still maintained at the route processor in a distributed forwarding
	system.		system.
	Requirements Language		Requirements Language
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in RFC 2119 [RFC2119].		document are to be interpreted as described in RFC 2119 [RFC2119].
	skipping to change at page 1, line 46 ¶		skipping to change at page 1, line 46 ¶
	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 May 6, 2021.		This Internet-Draft will expire on November 7, 2021.
	Copyright Notice		Copyright Notice
	Copyright (c) 2020 IETF Trust and the persons identified as the		Copyright (c) 2021 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 46 ¶		skipping to change at page 2, line 46 ¶
	15. References . . . . . . . . . . . . . . . . . . . . . . . . . 11		15. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
	15.1. Normative References . . . . . . . . . . . . . . . . . . 11		15.1. Normative References . . . . . . . . . . . . . . . . . . 11
	15.2. Informative References . . . . . . . . . . . . . . . . . 12		15.2. Informative References . . . . . . . . . . . . . . . . . 12
	Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 13		Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 13
	A.1. Dynamic Subscription . . . . . . . . . . . . . . . . . . 13		A.1. Dynamic Subscription . . . . . . . . . . . . . . . . . . 13
	A.2. Configured Subscription . . . . . . . . . . . . . . . . . 17		A.2. Configured Subscription . . . . . . . . . . . . . . . . . 17
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19
	1. Introduction		1. Introduction
	The mechanism to support a subscription to a continuous and		The mechanism to support a subscription of a continuous and
	customized stream of updates from a YANG datastore is defined in		customized stream of updates from a YANG datastore is defined in
	[RFC8639] and [RFC8641]. Requirements for Subscription to YANG		[RFC8639] and [RFC8641]. Requirements for Subscription to YANG
	Datastores are defined in [RFC7923]		Datastores are defined in [RFC7923]
	By streaming data from publishers to receivers, much better		By streaming data from publishers to receivers, much better
	performance and fine-grained sampling can be achieved than with		performance and fine-grained sampling can be achieved than with
	polling. In a distributed forwarding system, the packet forwarding		polling. In a distributed forwarding system, the packet forwarding
	is delegated to multiple processors on line cards. To not to		is delegated to multiple processors on line cards. To not to
	overhelm the route processor resources, it is not uncomon that data		overwhelm the route processor resources, it is not uncommon that data
	records are published directly from processors on line cards to		records are published directly from processors on line cards to
	target Receivers to further increase efficency on the routing system.		target Receivers to further increase efficiency on the routing
			system.
	This documents complement the general subscription requirements		This documents complement the general subscription requirements
	defined in section 4.2.1 of [RFC7923] by the paragraph: A		defined in section 4.2.1 of [RFC7923] by the paragraph: A
	Subscription Service MAY support the ability to export from multiple		Subscription Service MAY support the ability to export from multiple
	software processes on a single routing system and expose the		software processes on a single routing system and expose the
	information which software process produced which message to maintain		information which software process produced which message to maintain
	data integrity.		data integrity.
	2. Terminologies		2. Terminologies
	skipping to change at page 3, line 49 ¶		skipping to change at page 3, line 50 ¶
	group of Publishers can expose to the Subscriber.		group of Publishers can expose to the Subscriber.
	Component Capability: is the subscription capability that each		Component Capability: is the subscription capability that each
	Publisher can expose to the Subscriber.		Publisher can expose to the Subscriber.
	Master: is the Publisher that interacts with the Subscriber to deal		Master: is the Publisher that interacts with the Subscriber to deal
	with the Global Subscription. It decomposes the Global Subscription		with the Global Subscription. It decomposes the Global Subscription
	to multiple Component Subscriptions and interacts with the Agents.		to multiple Component Subscriptions and interacts with the Agents.
	Agent: is the Publisher that interacts with the Master to deal with		Agent: is the Publisher that interacts with the Master to deal with
	the Component Subscription and pushing the data to the collector.		the Component Subscription and pushing the data to the Receiver.
	Observation Domain: An Observation Domain is the largest set of		Observation Domain: An Observation Domain is the largest set of
	Observation Points for which metrics can be collected by a metering		Observation Points for which metrics can be collected by a metering
	process. For example, a router line card may be an Observation		process. For example, a router line card may be an Observation
	Domain if it is composed of several interfaces, each of which is an		Domain if it is composed of several interfaces, each of which is an
	Observation Point. In the YANG notification messages it generates,		Observation Point. In the YANG notification messages it generates,
	the Observation Domain includes its Observation Domain ID, which is		the Observation Domain includes its Observation Domain ID, which is
	unique per publisher process. That way, the collecting process can		unique per publisher process. That way, the collecting process can
	identify the specific Observation Domain from the publisher that		identify the specific Observation Domain from the publisher that
	sends the YANG notification messages. Every Observation Point is		sends the YANG notification messages. Every Observation Point is
	associated with an Observation Domain.		associated with an Observation Domain.
	Observation Domain ID: A 32-bit identifier of the Observation Domain		Observation Domain ID: A 32-bit identifier of the Observation Domain
	that is locally unique to the publisher process. The publisher		that is locally unique to the publisher process. The publisher
	process uses the Observation Domain ID to uniquely identify to the		processes uses the Observation Domain ID to uniquely identify to the
	collecting process the Observation Domain that meters the metrics.		collecting process the Observation Domain that meters the metrics.
	Receivers SHOULD use the transport session and the Observation Domain		Receivers SHOULD use the transport session and the Observation Domain
	ID field to separate different publisher streams originating from the		ID field to separate different publisher streams originating from the
	same publisher.		same publisher.
	3. Motivation		3. Motivation
	Lost and corrupt YANG notification messages need to be recognized at		Lost and corrupt YANG notification messages need to be recognized at
	the receiver to ensure data integrity even when multiple publisher		the receiver to ensure data integrity even when multiple publisher
	processes publishing from the same transport session.		processes publishing from the same transport session.
	skipping to change at page 4, line 43 ¶		skipping to change at page 4, line 43 ¶
	is described in Section 3.2 of UDP based transport		is described in Section 3.2 of UDP based transport
	[I-D.ietf-netconf-udp-notif].		[I-D.ietf-netconf-udp-notif].
	4. Solution Overview		4. Solution Overview
	Figure 2 below shows the distributed data export framework.		Figure 2 below shows the distributed data export framework.
	A collector usually includes two components,		A collector usually includes two components,
	o the Subscriber generates the subscription instructions to express		o the Subscriber generates the subscription instructions to express
	what and how the collector want to receive the data;		what and how the Receiver want to receive the data;
	o the Receiver is the target for the data publication.		o the Receiver is the target for the data publication.
	For one subscription, there are one or more Receivers. And the		For one subscription, there can be one or more Receivers. And the
	Subscriber does not necessarily share the same IP address as the		Subscriber does not necessarily share the same IP address as the
	Receivers.		Receivers.
	In this framework, the Publisher pushes data to the Receiver		In this framework, the Publisher pushes data to the Receiver
	according to the subscription. The Publisher is either in the Master		according to the subscription. The Publisher is either in the Master
	or Agent role. The Master knows all the capabilities that his Agents		or Agent role. The Master knows all the capabilities that his Agents
	are able to provide and exposes the Global Capability to the		are able to provide and exposes the Global Capability to the
	collector. The Subscriber maintains the Global Subscription at the		collector. The Subscriber maintains the Global Subscription at the
	Master and disassembles the Global Subscription to multiple Component		Master and disassembles the Global Subscription to multiple Component
	Subscriptions, depending from which source data is needed. The		Subscriptions, depending from which source data is needed. The
	skipping to change at page 9, line 25 ¶		skipping to change at page 9, line 25 ¶
	grouping message-observation-domain-ids {		grouping message-observation-domain-ids {
	description		description
	"Provides a reusable list of message-observation-domain-ids.";		"Provides a reusable list of message-observation-domain-ids.";
	leaf-list message-observation-domain-id {		leaf-list message-observation-domain-id {
	type string;		type string;
	config false;		config false;
	ordered-by user;		ordered-by user;
	description		description
	"Software process which created the message (e.g.,		"Software process which created the message (e.g.,
	processor 1 on linecard 1). This field is		processor 1 on line card 1). This field is
	used to notify the collector the working originator.";		used to notify the collector the working originator.";
	}		}
	}		}
	augment "/sn:subscriptions/sn:subscription" {		augment "/sn:subscriptions/sn:subscription" {
	description		description
	"This augmentation allows the message		"This augmentation allows the message
	Observation Domain ID to be exposed for a subscription.";		Observation Domain ID to be exposed for a subscription.";
	uses message-observation-domain-ids;		uses message-observation-domain-ids;
	skipping to change at page 12, line 46 ¶		skipping to change at page 12, line 46 ¶
	<https://www.rfc-editor.org/info/rfc8639>.		<https://www.rfc-editor.org/info/rfc8639>.
	[RFC8641] Clemm, A. and E. Voit, "Subscription to YANG Notifications		[RFC8641] Clemm, A. and E. Voit, "Subscription to YANG Notifications
	for Datastore Updates", RFC 8641, DOI 10.17487/RFC8641,		for Datastore Updates", RFC 8641, DOI 10.17487/RFC8641,
	September 2019, <https://www.rfc-editor.org/info/rfc8641>.		September 2019, <https://www.rfc-editor.org/info/rfc8641>.
	15.2. Informative References		15.2. Informative References
	[I-D.ietf-netconf-https-notif]		[I-D.ietf-netconf-https-notif]
	Jethanandani, M. and K. Watsen, "An HTTPS-based Transport		Jethanandani, M. and K. Watsen, "An HTTPS-based Transport
	for Configured Subscriptions", draft-ietf-netconf-https-		for YANG Notifications", draft-ietf-netconf-https-notif-08
	notif-05 (work in progress), October 2020.		(work in progress), February 2021.
	[I-D.ietf-netconf-notification-messages]		[I-D.ietf-netconf-notification-messages]
	Voit, E., Jenkins, T., Birkholz, H., Bierman, A., and A.		Voit, E., Jenkins, T., Birkholz, H., Bierman, A., and A.
	Clemm, "Notification Message Headers and Bundles", draft-		Clemm, "Notification Message Headers and Bundles", draft-
	ietf-netconf-notification-messages-08 (work in progress),		ietf-netconf-notification-messages-08 (work in progress),
	November 2019.		November 2019.
	[I-D.ietf-netconf-udp-notif]		[I-D.ietf-netconf-udp-notif]
	Zhou, T., Zheng, G., Lucente, P., Graf, T., and P.		Zhou, T., Zheng, G., Lucente, P., Graf, T., and P.
	Francois, "UDP-based Transport for Configured		Francois, "UDP-based Transport for Configured
End of changes. 15 change blocks.
	16 lines changed or deleted		17 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/