draft-ietf-netconf-configuration-tracing-02.txt		draft-ietf-netconf-configuration-tracing-03.txt
	OPSAWG J. Quilbeuf		OPSAWG J. Quilbeuf
	Internet-Draft B. Claise		Internet-Draft B. Claise
	Intended status: Standards Track Huawei		Intended status: Standards Track Huawei
	Expires: 21 April 2025 T. Graf		Expires: 24 April 2025 T. Graf
	Swisscom		Swisscom
	D. Lopez		D. Lopez
	Telefonica I+D		Telefonica I+D
	Q. Sun		Q. Sun
	China Telecom		China Telecom
	18 October 2024		21 October 2024
	External Trace ID for Configuration Tracing		External Trace ID for Configuration Tracing
	draft-ietf-netconf-configuration-tracing-02		draft-ietf-netconf-configuration-tracing-03
	Abstract		Abstract
	Network equipment are often configured by a variety of network		Network equipment are often configured by a variety of network
	management systems (NMS), protocols, and teams. If a network issue		management systems (NMS), protocols, and teams. If a network issue
	arises (e.g., because of a wrong configuration change), it is		arises (e.g., because of a wrong configuration change), it is
	important to quickly identify the root cause and obtain the reason		important to quickly identify the root cause and obtain the reason
	for pushing that modification. Another potential network issue can		for pushing that modification. Another potential network issue can
	stem from concurrent NMSes with overlapping intents, each having		stem from concurrent NMSes with overlapping intents, each having
	their own tasks to perform. In such a case, it is important to map		their own tasks to perform. In such a case, it is important to map
	skipping to change at page 2, line 20 ¶		skipping to change at page 2, line 20 ¶
	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 21 April 2025.		This Internet-Draft will expire on 24 April 2025.
	Copyright Notice		Copyright Notice
	Copyright (c) 2024 IETF Trust and the persons identified as the		Copyright (c) 2024 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 (https://trustee.ietf.org/		Provisions Relating to IETF Documents (https://trustee.ietf.org/
	license-info) in effect on the date of publication of this document.		license-info) in effect on the date of publication of this document.
	Please review these documents carefully, as they describe your rights		Please review these documents carefully, as they describe your rights
	skipping to change at page 3, line 40 ¶		skipping to change at page 3, line 40 ¶
	support new services. Therefore, we need to be able to trace a		support new services. Therefore, we need to be able to trace a
	configuration modification on a device back to the reason that		configuration modification on a device back to the reason that
	triggered that modification, for instance in a NMS, whether the		triggered that modification, for instance in a NMS, whether the
	controller or the orchestrator.		controller or the orchestrator.
	This specification focuses only on configuration pushed via NETCONF		This specification focuses only on configuration pushed via NETCONF
	[RFC6241] or RESTCONF [RFC8040]. The rationale for this choice is		[RFC6241] or RESTCONF [RFC8040]. The rationale for this choice is
	that NETCONF is better suited for normalization than other protocols		that NETCONF is better suited for normalization than other protocols
	(SNMP, CLI). Another reason is that the notion of trace context,		(SNMP, CLI). Another reason is that the notion of trace context,
	useful to track configuration modifications, has been ported to		useful to track configuration modifications, has been ported to
	NETCONF in [I-D.rogaglia-netconf-trace-ctx-extension] and RESTCONF in		NETCONF in [I-D.ietf-netconf-trace-ctx-extension] and RESTCONF in
	[I-D.rogaglia-netconf-restconf-trace-ctx-headers].		[I-D.ietf-netconf-restconf-trace-ctx-headers].
	The same network element, or NETCONF [RFC6241] server, can be		The same network element, or NETCONF [RFC6241] server, can be
	configured by different NMSs or NETCONF clients. If an issue arises,		configured by different NMSs or NETCONF clients. If an issue arises,
	one of the starting points for investigation is the configuration		one of the starting points for investigation is the configuration
	modification on the devices supporting the impacted service. In the		modification on the devices supporting the impacted service. In the
	best case, there is a dedicated user for each client and the		best case, there is a dedicated user for each client and the
	timestamp of the modification allows tracing the problematic		timestamp of the modification allows tracing the problematic
	modification to its cause. In the worst case, everything is done by		modification to its cause. In the worst case, everything is done by
	the same user and some more correlations must be done to trace the		the same user and some more correlations must be done to trace the
	problematic modification to its source.		problematic modification to its source.
	This document specifies a mechanism to automatically map the		This document specifies a mechanism to automatically map the
	configuration modifications to their source, up to a specific NMS		configuration modifications to their source, up to a specific NMS
	service request. Practically, this mechanism annotates configuration		service request. Practically, this mechanism annotates configuration
	changes on the configured element with sufficient information to		changes on the configured element with sufficient information to
	unambiguously identify the corresponding transaction, if any, on the		unambiguously identify the corresponding transaction, if any, on the
	element that requested the configuration modification. It reuses the		element that requested the configuration modification. It reuses the
	concept of Trace Context [W3C-Trace-Context] applied to NETCONF as in		concept of Trace Context [W3C-Trace-Context] applied to NETCONF as in
	[I-D.rogaglia-netconf-trace-ctx-extension] The information needed to		[I-D.ietf-netconf-trace-ctx-extension] The information needed to
	trace the configuration is stored in a new YANG module that maps a		trace the configuration is stored in a new YANG module that maps a
	local configuration change to some additional metadata. The		local configuration change to some additional metadata. The
	additional metadata contains the trace ID, and, if the local change		additional metadata contains the trace ID, and, if the local change
	is not the beginning of the trace, the ID of the client that		is not the beginning of the trace, the ID of the client that
	triggered the local-change. In that sense, it is an instance of the		triggered the local-change. In that sense, it is an instance of the
	YANG DataStore implementation of the Trace Context as proposed in		YANG DataStore implementation of the Trace Context as proposed in
	Section 1.2 of [I-D.rogaglia-netconf-trace-ctx-extension].		Section 1.2 of [I-D.ietf-netconf-trace-ctx-extension].
	2. Terminology		2. Terminology
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and		"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
	"OPTIONAL" in this document are to be interpreted as described in BCP		"OPTIONAL" in this document are to be interpreted as described in BCP
	14 [RFC2119] [RFC8174] when, and only when, they appear in all		14 [RFC2119] [RFC8174] when, and only when, they appear in all
	capitals, as shown here.		capitals, as shown here.
	This document uses the terms client and server from [RFC6241].		This document uses the terms client and server from [RFC6241].
	skipping to change at page 4, line 51 ¶		skipping to change at page 4, line 51 ¶
	3. Use cases		3. Use cases
	This document was written with autonomous networks in mind. We		This document was written with autonomous networks in mind. We
	assume that an existing monitoring or assurance system, such as		assume that an existing monitoring or assurance system, such as
	described in [RFC9417], is able to detect and report network		described in [RFC9417], is able to detect and report network
	anomalies , e.g. SLA violations, intent violations, network failure,		anomalies , e.g. SLA violations, intent violations, network failure,
	or simply a customer issue. Here are the use cases for the proposed		or simply a customer issue. Here are the use cases for the proposed
	YANG module; they are extensions of the "Provisioning root cause		YANG module; they are extensions of the "Provisioning root cause
	analysis" use case presented in Section 1.3.1 of		analysis" use case presented in Section 1.3.1 of
	[I-D.rogaglia-netconf-trace-ctx-extension].		[I-D.ietf-netconf-trace-ctx-extension].
	3.1. Configuration Mistakes		3.1. Configuration Mistakes
	Taking into account that many network anomalies are due to		Taking into account that many network anomalies are due to
	configuration mistakes, this mechanism allows to find out whether the		configuration mistakes, this mechanism allows to find out whether the
	offending configuration modification was triggered by a tracing-		offending configuration modification was triggered by a tracing-
	enabled client/NMS. In such a case, we can map the offending		enabled client/NMS. In such a case, we can map the offending
	configuration modification id on a server/NE to a local configuration		configuration modification id on a server/NE to a local configuration
	modification id on the client/NMS. Assuming that this mechanism (the		modification id on the client/NMS. Assuming that this mechanism (the
	YANG module) is implemented on the controller, we can recursively		YANG module) is implemented on the controller, we can recursively
	skipping to change at page 6, line 28 ¶		skipping to change at page 6, line 28 ¶
	This document assumes that each NETCONF client for which		This document assumes that each NETCONF client for which
	configuration must be traced (for instance orchestrator and		configuration must be traced (for instance orchestrator and
	controllers) has a unique client ID among the other NETCONF clients		controllers) has a unique client ID among the other NETCONF clients
	in the network. Such an ID could be an IP address or a host name.		in the network. Such an ID could be an IP address or a host name.
	The mechanism for providing and defining this client ID is out of		The mechanism for providing and defining this client ID is out of
	scope of the current document.		scope of the current document.
	4.3. Instantiating the YANG module		4.3. Instantiating the YANG module
	[I-D.rogaglia-netconf-trace-ctx-extension] defines a NETCONF		[I-D.ietf-netconf-trace-ctx-extension] defines a NETCONF extension
	extension providing the trace context from [W3C-Trace-Context].		providing the trace context from [W3C-Trace-Context]. Using this
	Using this mechanism, the NETCONF server captures the trace-id, when		mechanism, the NETCONF server captures the trace-id, when available,
	available, and maps it to a local commit ID, by populating the YANG		and maps it to a local commit ID, by populating the YANG module.
	module.
	The trace context from W3C provides a parent-id. This parent-id does		The trace context from W3C provides a parent-id. This parent-id does
	not identify a particular server or NMS but rather one request in the		not identify a particular server or NMS but rather one request in the
	chain of HTTP requests constituting the trace. Similarly to the		chain of HTTP requests constituting the trace. Similarly to the
	passing of the trace context in		passing of the trace context in
	[I-D.rogaglia-netconf-trace-ctx-extension], we propose an XML		[I-D.ietf-netconf-trace-ctx-extension], we propose an XML attribute
	attribute on NETCONF messages to pass the client-id. The attribute		on NETCONF messages to pass the client-id. The attribute name is
	name is "client-id" and the namespace is the namespace of the YANG		"client-id" and the namespace is the namespace of the YANG module
	module from Section 5, namely 'urn:ietf:params:xml:ns:yang:ietf-		from Section 5, namely 'urn:ietf:params:xml:ns:yang:ietf-external-
	external-transaction-id'. An example of a commit message including		transaction-id'. An example of a commit message including the
	the client-id is shown in Figure 4.		client-id is shown in Figure 4.
	+---------------+		+---------------+
	| Orchestrator |		| Orchestrator |
	+---------------+		+---------------+
	| tr-1, tx-1		| tr-1, tx-1
	v		v
	+---------------+		+---------------+
	| Controller |		| Controller |
	+---------------+		+---------------+
	tr-1, tx-2 | | tr-1, tx-3		tr-1, tx-2 | | tr-1, tx-3
	skipping to change at page 7, line 25 ¶		skipping to change at page 7, line 25 ¶
	+-----+ +-----+		+-----+ +-----+
	| NE1 | | NE2 |		| NE1 | | NE2 |
	+-----+ +-----+		+-----+ +-----+
	Figure 1: Example of Hierarchical Configuration. tx: transaction.		Figure 1: Example of Hierarchical Configuration. tx: transaction.
	tr: trace.		tr: trace.
	In Figure 1, the transactions 'tx-1', 'tx-2' and 'tx-3' are sent via		In Figure 1, the transactions 'tx-1', 'tx-2' and 'tx-3' are sent via
	NETCONF. The NETCONF RPC used, most likely 'commit' in our use case,		NETCONF. The NETCONF RPC used, most likely 'commit' in our use case,
	is annotated with the 'traceparent' annotation as defined in		is annotated with the 'traceparent' annotation as defined in
	[I-D.rogaglia-netconf-trace-ctx-extension]. The traceparent		[I-D.ietf-netconf-trace-ctx-extension]. The traceparent annotation
	annotation has the same trace id 'tr-1' for each of these		has the same trace id 'tr-1' for each of these transactions.
	transactions. Additionally, for each transaction the client id is		Additionally, for each transaction the client id is passed via the
	passed via the 'client-id' annotation. For 'tx-1' the client-id is		'client-id' annotation. For 'tx-1' the client-id is the id of the
	the id of the Orchestrator. For 'tx-2' and 'tx-3', the client is the		Orchestrator. For 'tx-2' and 'tx-3', the client is the id of the
	id of the Controller.		Controller.
	It is technically possible that several clients push configuration to		It is technically possible that several clients push configuration to
	the candidate configuration datastore and only one of them commits		the candidate configuration datastore and only one of them commits
	the changes to the running configuration datastore. From the running		the changes to the running configuration datastore. From the running
	configuration datastore perspective, which is the effective one,		configuration datastore perspective, which is the effective one,
	there is a single modification, but caused by several clients, which		there is a single modification, but caused by several clients, which
	means that this modification should have several corresponding		means that this modification should have several corresponding
	client-ids. Although, this case is technically possible, it is a bad		client-ids. Although, this case is technically possible, it is a bad
	practice. We won’t cover it in this document. In other terms, we		practice. We won’t cover it in this document. In other terms, we
	assume that a given configuration modification on a server is caused		assume that a given configuration modification on a server is caused
	skipping to change at page 14, line 13 ¶		skipping to change at page 14, line 13 ¶
	on [W3C-Trace-Context], we could also use associated mechanisms		on [W3C-Trace-Context], we could also use associated mechanisms
	for collecting and representing trace data such as OTLP. For		for collecting and representing trace data such as OTLP. For
	instance, we could define a YANG model matching the OTLP		instance, we could define a YANG model matching the OTLP
	protobuffer definition (draft: https://github.com/rgaglian/ietf-		protobuffer definition (draft: https://github.com/rgaglian/ietf-
	netconf-trace-context-extension/blob/main/ietf-netconf-otlp-		netconf-trace-context-extension/blob/main/ietf-netconf-otlp-
	protocol.tree). In that case the client-id could be a specific		protocol.tree). In that case the client-id could be a specific
	attribute of the spans list.		attribute of the spans list.
	10. Normative References		10. Normative References
	[I-D.ietf-netconf-transaction-id]		[I-D.ietf-netconf-restconf-trace-ctx-headers]
	Lindblad, J., "Transaction ID Mechanism for NETCONF", Work
	in Progress, Internet-Draft, draft-ietf-netconf-
	transaction-id-01, 4 July 2023,
	<https://datatracker.ietf.org/doc/html/draft-ietf-netconf-
	transaction-id-01>.
	[I-D.rogaglia-netconf-restconf-trace-ctx-headers]
	Gagliano, R., Larsson, K., and J. Lindblad, "RESTCONF		Gagliano, R., Larsson, K., and J. Lindblad, "RESTCONF
	Extension to support Trace Context Headers", Work in		Extension to Support Trace Context Headers", Work in
	Progress, Internet-Draft, draft-rogaglia-netconf-restconf-		Progress, Internet-Draft, draft-ietf-netconf-restconf-
	trace-ctx-headers-00, 6 July 2023,		trace-ctx-headers-02, 25 September 2024,
	<https://datatracker.ietf.org/doc/html/draft-rogaglia-		<https://datatracker.ietf.org/doc/html/draft-ietf-netconf-
	netconf-restconf-trace-ctx-headers-00>.		restconf-trace-ctx-headers-02>.
	[I-D.rogaglia-netconf-trace-ctx-extension]		[I-D.ietf-netconf-trace-ctx-extension]
	Gagliano, R., Larsson, K., and J. Lindblad, "NETCONF		Gagliano, R., Larsson, K., and J. Lindblad, "NETCONF
	Extension to support Trace Context propagation", Work in		Extension to support Trace Context propagation", Work in
	Progress, Internet-Draft, draft-rogaglia-netconf-trace-		Progress, Internet-Draft, draft-ietf-netconf-trace-ctx-
	ctx-extension-03, 6 July 2023,		extension-01, 8 July 2024,
	<https://datatracker.ietf.org/doc/html/draft-rogaglia-		<https://datatracker.ietf.org/doc/html/draft-ietf-netconf-
	netconf-trace-ctx-extension-03>.		trace-ctx-extension-01>.
			[I-D.ietf-netconf-transaction-id]
			Lindblad, J., "Transaction ID Mechanism for NETCONF", Work
			in Progress, Internet-Draft, draft-ietf-netconf-
			transaction-id-07, 19 October 2024,
			<https://datatracker.ietf.org/doc/html/draft-ietf-netconf-
			transaction-id-07>.
	[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>.
	[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,		[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
	and A. Bierman, Ed., "Network Configuration Protocol		and A. Bierman, Ed., "Network Configuration Protocol
	(NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,		(NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
	<https://www.rfc-editor.org/info/rfc6241>.		<https://www.rfc-editor.org/info/rfc6241>.
	skipping to change at page 16, line 17 ¶		skipping to change at page 16, line 17 ¶
	w3ctc:traceparent=		w3ctc:traceparent=
	"00-4bf92f3577b34da6a3ce929d0e0e4736-00f067aa0ba902b7-01"		"00-4bf92f3577b34da6a3ce929d0e0e4736-00f067aa0ba902b7-01"
	ext-txid:client-id="controller-01">		ext-txid:client-id="controller-01">
	<commit/>		<commit/>
	</rpc>		</rpc>
	Figure 4: Example of NETCONF commit RPC with annotations		Figure 4: Example of NETCONF commit RPC with annotations
	In Figure 4, we present an RPC annotated with the traceparent and the		In Figure 4, we present an RPC annotated with the traceparent and the
	client-id. The traceparent example is taken from		client-id. The traceparent example is taken from
	[I-D.rogaglia-netconf-trace-ctx-extension]. The client-id annotation		[I-D.ietf-netconf-trace-ctx-extension]. The client-id annotation is
	is defined in our YANG module. Here the client-id passed is		defined in our YANG module. Here the client-id passed is
	'controller-01'.		'controller-01'.
	Acknowledgements		Acknowledgements
	The authors would like to thank Mohamed Boucadair, Jan Linblad and		The authors would like to thank Mohamed Boucadair, Jan Linblad and
	Roque Gagliano for their reviews and propositions.		Roque Gagliano for their reviews and propositions.
	Authors' Addresses		Authors' Addresses
	Jean Quilbeuf		Jean Quilbeuf
End of changes. 16 change blocks.
	46 lines changed or deleted		45 lines changed or added
This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/