draft-ietf-opsawg-yang-vpn-service-pm-04.txt		draft-ietf-opsawg-yang-vpn-service-pm-05.txt
	OPSAWG Working Group B. Wu, Ed.		OPSAWG Working Group B. Wu, Ed.
	Internet-Draft Q. Wu, Ed.		Internet-Draft Q. Wu, Ed.
	Intended status: Standards Track Huawei		Intended status: Standards Track Huawei
	Expires: 22 September 2022 M. Boucadair, Ed.		Expires: 10 October 2022 M. Boucadair, Ed.
	Orange		Orange
	O. Gonzalez de Dios		O. Gonzalez de Dios
	Telefonica		Telefonica
	B. Wen		B. Wen
	Comcast		Comcast
	21 March 2022		8 April 2022
	A YANG Model for Network and VPN Service Performance Monitoring		A YANG Model for Network and VPN Service Performance Monitoring
	draft-ietf-opsawg-yang-vpn-service-pm-04		draft-ietf-opsawg-yang-vpn-service-pm-05
	Abstract		Abstract
	The data model for network topologies defined in RFC 8345 introduces		The data model for network topologies defined in RFC 8345 introduces
	vertical layering relationships between networks that can be		vertical layering relationships between networks that can be
	augmented to cover network and service topologies. This document		augmented to cover network and service topologies. This document
	defines a YANG module for performance monitoring (PM) of both		defines a YANG module for performance monitoring (PM) of both
	networks and VPN services that can be used to monitor and manage		networks and VPN services that can be used to monitor and manage
	network performance on the topology at higher layer or the service		network performance on the topology at higher layer or the service
	topology between VPN sites.		topology between VPN sites.
	skipping to change at page 1, line 42 ¶		skipping to change at page 1, line 42 ¶
	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 22 September 2022.		This Internet-Draft will expire on 10 October 2022.
	Copyright Notice		Copyright Notice
	Copyright (c) 2022 IETF Trust and the persons identified as the		Copyright (c) 2022 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 2, line 29 ¶		skipping to change at page 2, line 29 ¶
	3. Network and VPN Service Performance Monitoring Model Usage . 4		3. Network and VPN Service Performance Monitoring Model Usage . 4
	3.1. Collecting Data via Pub/Sub Mechanism . . . . . . . . . . 5		3.1. Collecting Data via Pub/Sub Mechanism . . . . . . . . . . 5
	3.2. Collecting Data On-demand . . . . . . . . . . . . . . . . 6		3.2. Collecting Data On-demand . . . . . . . . . . . . . . . . 6
	4. Description of The Data Model . . . . . . . . . . . . . . . . 6		4. Description of The Data Model . . . . . . . . . . . . . . . . 6
	4.1. Layering Relationship between Multiple Layers of		4.1. Layering Relationship between Multiple Layers of
	Topology . . . . . . . . . . . . . . . . . . . . . . . . 6		Topology . . . . . . . . . . . . . . . . . . . . . . . . 6
	4.2. Network Level . . . . . . . . . . . . . . . . . . . . . . 8		4.2. Network Level . . . . . . . . . . . . . . . . . . . . . . 8
	4.3. Node Level . . . . . . . . . . . . . . . . . . . . . . . 9		4.3. Node Level . . . . . . . . . . . . . . . . . . . . . . . 9
	4.4. Link and Termination Point Level . . . . . . . . . . . . 10		4.4. Link and Termination Point Level . . . . . . . . . . . . 10
	5. Network and VPN Service Performance Monitoring YANG Module . 14		5. Network and VPN Service Performance Monitoring YANG Module . 14
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 28		6. Security Considerations . . . . . . . . . . . . . . . . . . . 29
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30
	8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 30		8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 30
	9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 30		9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 30
	10. References . . . . . . . . . . . . . . . . . . . . . . . . . 30		10. References . . . . . . . . . . . . . . . . . . . . . . . . . 31
	10.1. Normative References . . . . . . . . . . . . . . . . . . 30		10.1. Normative References . . . . . . . . . . . . . . . . . . 31
	10.2. Informative References . . . . . . . . . . . . . . . . . 32		10.2. Informative References . . . . . . . . . . . . . . . . . 33
	Appendix A. Illustrating Examples . . . . . . . . . . . . . . . 34		Appendix A. Illustrating Examples . . . . . . . . . . . . . . . 35
	A.1. VPN Performance Subscription Example . . . . . . . . . . 34		A.1. VPN Performance Subscription Example . . . . . . . . . . 35
	A.2. Example of VPN Performance Snapshot . . . . . . . . . . . 35		A.2. Example of VPN Performance Snapshot . . . . . . . . . . . 36
	A.3. Example of Percentile Monitoring . . . . . . . . . . . . 37		A.3. Example of Percentile Monitoring . . . . . . . . . . . . 38
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 37		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 38
	1. Introduction		1. Introduction
	[RFC8969] describes a framework for automating service and network		[RFC8969] describes a framework for automating service and network
	management with YANG models. It defines that the performance		management with YANG models. It defines that the performance
	measurement telemetry model to be tied with the service, such as		measurement telemetry model to be tied with the service, such as
	Layer 3 VPN and Layer 2 VPN, or network models to monitor the overall		Layer 3 VPN and Layer 2 VPN, or network models to monitor the overall
	network performance or Service Level Agreement (SLA).		network performance or Service Level Agreement (SLA).
	The performance of VPN services is associated with the performance		The performance of VPN services is associated with the performance
	skipping to change at page 4, line 8 ¶		skipping to change at page 4, line 8 ¶
	L2VPN Layer 2 Virtual Private Network		L2VPN Layer 2 Virtual Private Network
	L3VPN Layer 3 Virtual Private Network		L3VPN Layer 3 Virtual Private Network
	L2NM L2VPN Network Model		L2NM L2VPN Network Model
	L3NM L3VPN Network Model		L3NM L3VPN Network Model
	MPLS Multiprotocol Label Switching		MPLS Multiprotocol Label Switching
	OAM Operations, Administration, and Maintenance		OAM Operations, Administration, and Maintenance
	OWAMP One-Way Active Measurement Protocol		OWAMP One-Way Active Measurement Protocol
	PE Provider Edge		PE Provider Edge
	PM Performance Monitoring		PM Performance Monitoring
			SLA Service Level Agreements
	TWAMP Two-Way Active Measurement Protocol		TWAMP Two-Way Active Measurement Protocol
	VPLS Virtual Private LAN Service		VPLS Virtual Private LAN Service
	VPN Virtual Private Network		VPN Virtual Private Network
	3. Network and VPN Service Performance Monitoring Model Usage		3. Network and VPN Service Performance Monitoring Model Usage
	Models are key for automating network management operations.		Models are key for automating network management operations.
	According to [RFC8969], together with service and network models,		According to [RFC8969], together with service and network models,
	performance measurement telemetry models are needed to monitor		performance measurement telemetry models are needed to monitor
	network performance to meet specific service requirements (typically		network performance to meet specific service requirements (typically
	skipping to change at page 5, line 8 ¶		skipping to change at page 5, line 8 ¶
	architecture described in [RFC8309], the network and VPN service		architecture described in [RFC8309], the network and VPN service
	performance monitoring (PM) model can be used to expose a set of		performance monitoring (PM) model can be used to expose a set of
	performance information to the above layer. Such information can be		performance information to the above layer. Such information can be
	used by an orchestrator to subscribe to performance data. The		used by an orchestrator to subscribe to performance data. The
	network controller will then notify the orchestrator about		network controller will then notify the orchestrator about
	corresponding parameter changes.		corresponding parameter changes.
	Before using the model, the controller needs to establish complete		Before using the model, the controller needs to establish complete
	topology visibility of the network and VPN. For example, the		topology visibility of the network and VPN. For example, the
	controller can use information from [RFC8345], [I-D.ietf-opsawg-sap]		controller can use information from [RFC8345], [I-D.ietf-opsawg-sap]
	or VPN instances. Then the controller derive network or VPN level		or VPN instances. Then the controller derives network or VPN level
	performance data by aggregating (and filtering) lower-level data		performance data by aggregating (and filtering) lower-level data
	collected via monitoring counters of the involved devices.		collected via monitoring counters of the involved devices.
	The network or VPN performance data can be based on different		The network or VPN performance data can be based on different
	sources. For example, the performance monitoring data per link in		sources. For example, the performance monitoring data per link in
	the underlying network can be collected using a network performance		the underlying network can be collected using a network performance
	measurement method such as One-Way Active Measurement Protocol		measurement method such as One-Way Active Measurement Protocol
	(OWAMP) [RFC4656], Two-Way Active Measurement Protocol (TWAMP)		(OWAMP) [RFC4656], Two-Way Active Measurement Protocol (TWAMP)
	[RFC5357], and Multiprotocol Label Switching (MPLS) Loss and Delay		[RFC5357], and Multiprotocol Label Switching (MPLS) Loss and Delay
	Measurement [RFC6374]. The performance monitoring information		Measurement [RFC6374]. The performance monitoring information
	skipping to change at page 5, line 43 ¶		skipping to change at page 5, line 43 ¶
	operational data of VPN instances, VPN interfaces, or tunnels, the		operational data of VPN instances, VPN interfaces, or tunnels, the
	network controller can specifically subscribe to metric-specific data		network controller can specifically subscribe to metric-specific data
	using the tagging methods defined in [I-D.ietf-netmod-node-tags].		using the tagging methods defined in [I-D.ietf-netmod-node-tags].
	3.1. Collecting Data via Pub/Sub Mechanism		3.1. Collecting Data via Pub/Sub Mechanism
	Some applications such as service-assurance applications, which must		Some applications such as service-assurance applications, which must
	maintain a continuous view of operational data and state, can use the		maintain a continuous view of operational data and state, can use the
	subscription model specified in [RFC8641] to subscribe to the		subscription model specified in [RFC8641] to subscribe to the
	specific network performance data or VPN service performance data		specific network performance data or VPN service performance data
	they are interested in, at the data source.		they are interested in, at the data source. For example, network or
			VPN topology updates may be obtained through on-change notifications
			[RFC8641]. For dynamic-changing PM data, various notifications can
			be specified to obtain more complete data. A periodic notification
			[RFC8641] can be specified to obtain real-time performance data, a
			replay notification defined in [RFC5277] or [RFC8639] can be
			specified to obtain historical data, or alarm notifications [RFC8632]
			can be specified to get alarms for the metrics which exceed or fall
			below the performance threshold.
	The data source can, then, use the network and VPN service assurance		The data source can, then, use the network and VPN service assurance
	model defined in this document and the YANG Push model [RFC8641] to		model defined in this document and the YANG Push model [RFC8641] to
	distribute specific telemetry data to target recipients.		distribute specific telemetry data to target recipients.
	3.2. Collecting Data On-demand		3.2. Collecting Data On-demand
	To obtain a snapshot of a large amount of performance data from a		To obtain a snapshot of a large amount of performance data from a
	network topology or VPN network, service-assurance applications may		network topology or VPN network, service-assurance applications may
	retrieve information using the network and VPN service PM model		retrieve information using the network and VPN service PM model
	skipping to change at page 9, line 42 ¶		skipping to change at page 9, line 42 ¶
	4.3. Node Level		4.3. Node Level
	The tree in Figure 6 is the node part of ietf-network-vpn-pm tree.		The tree in Figure 6 is the node part of ietf-network-vpn-pm tree.
	For network performance monitoring, a container of "pm-attributes" is		For network performance monitoring, a container of "pm-attributes" is
	augmented to the list of "node" that are defined in [RFC8345]. The		augmented to the list of "node" that are defined in [RFC8345]. The
	container includes the following attributes:		container includes the following attributes:
	"node-type": Indicates the device type of Provider Edge (PE),		"node-type": Indicates the device type of Provider Edge (PE),
	Provider (P) device, or Autonomous System Border Router (ASBR), so		Provider (P) device, or Autonomous System Border Router (ASBR) as
	that the performance metric between any two nodes each with		defined in [RFC4026] and [RFC4364], so that the performance metric
	specific node type can be reported.		between any two nodes each with specific node type can be
			reported.
	"entry-summary": Lists a set of IPv4 statistics, IPv6 statistics,		"entry-summary": Lists a set of IPv4 statistics, IPv6 statistics,
	and MAC statistics. The detailed statistics are specified		and MAC statistics. The detailed statistics are specified
	separately.		separately.
	For VPN service performance monitoring, the model defines one		For VPN service performance monitoring, the model defines one
	attribute:		attribute:
	"role": Defines the role in a particular VPN service topology. The		"role": Defines the role in a particular VPN service topology. The
	roles are taken from [RFC9181] (e.g., any-to-any-role, spoke-role,		roles are taken from [RFC9181] (e.g., any-to-any-role, spoke-role,
	skipping to change at page 11, line 11 ¶		skipping to change at page 11, line 14 ¶
	| | +--ro loss-ratio? percentage		| | +--ro loss-ratio? percentage
	| +--ro delay-statistics		| +--ro delay-statistics
	| | +--ro unit-value? identityref		| | +--ro unit-value? identityref
	| | +--ro min-delay-value? yang:gauge64		| | +--ro min-delay-value? yang:gauge64
	| | +--ro max-delay-value? yang:gauge64		| | +--ro max-delay-value? yang:gauge64
	| | +--ro low-delay-percentile? yang:gauge64		| | +--ro low-delay-percentile? yang:gauge64
	| | +--ro intermediate-delay-percentile? yang:gauge64		| | +--ro intermediate-delay-percentile? yang:gauge64
	| | +--ro high-delay-percentile? yang:gauge64		| | +--ro high-delay-percentile? yang:gauge64
	| +--ro jitter-statistics		| +--ro jitter-statistics
	| +--ro unit-value? identityref		| +--ro unit-value? identityref
	| +--ro min-jitter-value? yang:gauge32		| +--ro min-jitter-value? yang:gauge64
	| +--ro max-jitter-value? yang:gauge32		| +--ro max-jitter-value? yang:gauge64
	| +--ro low-jitter-percentile? yang:gauge32		| +--ro low-jitter-percentile? yang:gauge64
	| +--ro intermediate-jitter-percentile? yang:gauge32		| +--ro intermediate-jitter-percentile? yang:gauge64
	| +--ro high-jitter-percentile? yang:gauge32		| +--ro high-jitter-percentile? yang:gauge64
	+--ro one-way-pm-statistics-per-class* [class-id]		+--ro one-way-pm-statistics-per-class* [class-id]
	| +--ro class-id string		| +--ro class-id string
	| +--ro loss-statistics		| +--ro loss-statistics
	| | +--ro packet-loss-count? yang:counter64		| | +--ro packet-loss-count? yang:counter64
	| | +--ro loss-ratio? percentage		| | +--ro loss-ratio? percentage
	| +--ro delay-statistics		| +--ro delay-statistics
	| | +--ro unit-value? identityref		| | +--ro unit-value? identityref
	| | +--ro min-delay-value? yang:gauge64		| | +--ro min-delay-value? yang:gauge64
	| | +--ro max-delay-value? yang:gauge64		| | +--ro max-delay-value? yang:gauge64
	| | +--ro low-delay-percentile? yang:gauge64		| | +--ro low-delay-percentile? yang:gauge64
	| | +--ro intermediate-delay-percentile? yang:gauge64		| | +--ro intermediate-delay-percentile? yang:gauge64
	| | +--ro high-delay-percentile? yang:gauge64		| | +--ro high-delay-percentile? yang:gauge64
	| +--ro jitter-statistics		| +--ro jitter-statistics
	| +--ro unit-value? identityref		| +--ro unit-value? identityref
	| +--ro min-jitter-value? yang:gauge32		| +--ro min-jitter-value? yang:gauge64
	| +--ro max-jitter-value? yang:gauge32		| +--ro max-jitter-value? yang:gauge64
	| +--ro low-jitter-percentile? yang:gauge32		| +--ro low-jitter-percentile? yang:gauge64
	| +--ro intermediate-jitter-percentile? yang:gauge32		| +--ro intermediate-jitter-percentile? yang:gauge64
	| +--ro high-jitter-percentile? yang:gauge32		| +--ro high-jitter-percentile? yang:gauge64
	+--rw (vpn-pm-type)?		+--rw (vpn-pm-type)?
	+--:(inter-vpn-access-interface)		+--:(inter-vpn-access-interface)
	| +--rw inter-vpn-access-interface? empty		| +--rw inter-vpn-access-interface? empty
	+--:(underlay-tunnel)		+--:(underlay-tunnel)
	+--ro vpn-underlay-transport-type? identityref		+--ro vpn-underlay-transport-type? identityref
	augment /nw:networks/nw:network/nw:node/nt:termination-point:		augment /nw:networks/nw:network/nw:node/nt:termination-point:
	+--ro pm-statistics		+--ro pm-statistics
	+--ro reference-time? yang:date-and-time		+--ro reference-time? yang:date-and-time
	+--ro inbound-octets? yang:counter64		+--ro inbound-octets? yang:counter64
	+--ro inbound-unicast? yang:counter64		+--ro inbound-unicast? yang:counter64
	skipping to change at page 14, line 32 ¶		skipping to change at page 14, line 44 ¶
	network access defined in [RFC9182] or [I-D.ietf-opsawg-l2nm].		network access defined in [RFC9182] or [I-D.ietf-opsawg-l2nm].
	When multiple VPN network accesses are created using the same		When multiple VPN network accesses are created using the same
	physical port, finer-grained metrics can be monitored. If a TP is		physical port, finer-grained metrics can be monitored. If a TP is
	associated with only a single VPN, this list is not required.		associated with only a single VPN, this list is not required.
	5. Network and VPN Service Performance Monitoring YANG Module		5. Network and VPN Service Performance Monitoring YANG Module
	The "ietf-network-vpn-pm" module uses types defined in [RFC8345],		The "ietf-network-vpn-pm" module uses types defined in [RFC8345],
	[RFC6991], [RFC8532], and [RFC9181].		[RFC6991], [RFC8532], and [RFC9181].
	<CODE BEGINS> file "ietf-network-vpn-pm@2021-03-21.yang"		<CODE BEGINS> file "ietf-network-vpn-pm@2021-04-08.yang"
	module ietf-network-vpn-pm {		module ietf-network-vpn-pm {
	yang-version 1.1;		yang-version 1.1;
	namespace "urn:ietf:params:xml:ns:yang:ietf-network-vpn-pm";		namespace "urn:ietf:params:xml:ns:yang:ietf-network-vpn-pm";
	prefix nvp;		prefix nvp;
	import ietf-yang-types {		import ietf-yang-types {
	prefix yang;		prefix yang;
	reference		reference
	"RFC 6991: Common YANG Types";		"RFC 6991: Common YANG Types";
	}		}
	skipping to change at page 16, line 12 ¶		skipping to change at page 16, line 24 ¶
	This version of this YANG module is part of RFC XXXX		This version of this YANG module is part of RFC XXXX
	(https://www.rfc-editor.org/info/rfcXXXX); see the RFC itself		(https://www.rfc-editor.org/info/rfcXXXX); see the RFC itself
	for full legal notices.";		for full legal notices.";
	// RFC Ed.: update the date below with the date of RFC		// RFC Ed.: update the date below with the date of RFC
	// publication and remove this note.		// publication and remove this note.
	// RFC Ed.: replace XXXX with actual RFC number and remove		// RFC Ed.: replace XXXX with actual RFC number and remove
	// this note.		// this note.
	revision 2022-03-21 {		revision 2022-04-08 {
	description		description
	"Initial revision.";		"Initial revision.";
	reference		reference
	"RFC XXXX: A YANG Model for Network and VPN Service		"RFC XXXX: A YANG Model for Network and VPN Service
	Performance Monitoring";		Performance Monitoring";
	}		}
	identity node-type {		identity node-type {
	description		description
	"Base identity for node type";		"Base identity for node type";
	skipping to change at page 19, line 36 ¶		skipping to change at page 19, line 46 ¶
	"MAC statistics.";		"MAC statistics.";
	}		}
	}		}
	}		}
	grouping link-loss-statistics {		grouping link-loss-statistics {
	description		description
	"Grouping for per link error statistics.";		"Grouping for per link error statistics.";
	container loss-statistics {		container loss-statistics {
	description		description
	"Link loss summarized information. By default,		"One-way link loss summarized information.";
	one way measurement protocol (e.g., OWAMP) is used
	to measure one-way packet loss.";
	reference		reference
	"RFC 4656: A One-way Active Measurement Protocol (OWAMP)";		"RFC 4656: A One-way Active Measurement Protocol (OWAMP)
			ITU-T Y.1731: Operations, administration and
			maintenance (OAM) functions and mechanisms
			for Ethernet-based networks";
	leaf packet-loss-count {		leaf packet-loss-count {
	type yang:counter64;		type yang:counter64;
	description		description
	"Total received packet drops count.";		"Total received packet drops count.";
	}		}
	leaf loss-ratio {		leaf loss-ratio {
	type percentage;		type percentage;
	description		description
	"Loss ratio of the packets. Express as percentage		"Loss ratio of the packets. Express as percentage
	of packets lost with respect to packets sent.";		of packets lost with respect to packets sent.";
	skipping to change at page 20, line 4 ¶		skipping to change at page 20, line 17 ¶
	description		description
	"Total received packet drops count.";		"Total received packet drops count.";
	}		}
	leaf loss-ratio {		leaf loss-ratio {
	type percentage;		type percentage;
	description		description
	"Loss ratio of the packets. Express as percentage		"Loss ratio of the packets. Express as percentage
	of packets lost with respect to packets sent.";		of packets lost with respect to packets sent.";
	}		}
	}		}
	}		}
	grouping link-delay-statistics {		grouping link-delay-statistics {
	description		description
	"Grouping for per link delay statistics.";		"Grouping for per link delay statistics.";
	container delay-statistics {		container delay-statistics {
	description		description
	"Link delay summarized information. By default,		"One-way link delay summarized information.";
	one way measurement protocol (e.g., OWAMP) is used
	to measure delay.";
	reference		reference
	"RFC 4656: A One-way Active Measurement Protocol (OWAMP)";		"RFC 4656: A One-way Active Measurement Protocol (OWAMP)
			ITU-T Y.1731: Operations, administration and
			maintenance (OAM) functions and mechanisms
			for Ethernet-based networks";
	leaf unit-value {		leaf unit-value {
	type identityref {		type identityref {
	base lime:time-unit-type;		base lime:time-unit-type;
	}		}
	default "lime:milliseconds";		default "lime:milliseconds";
	description		description
	"Time units, where the options are s, ms, ns, etc.";		"Time units, where the options are s, ms, ns, etc.";
	}		}
	leaf min-delay-value {		leaf min-delay-value {
	type yang:gauge64;		type yang:gauge64;
	skipping to change at page 21, line 4 ¶		skipping to change at page 21, line 18 ¶
	description		description
	"Intermediate percentile of observed one-way delay with		"Intermediate percentile of observed one-way delay with
	specific measurement method.";		specific measurement method.";
	}		}
	leaf high-delay-percentile {		leaf high-delay-percentile {
	type yang:gauge64;		type yang:gauge64;
	description		description
	"High percentile of observed one-way delay with		"High percentile of observed one-way delay with
	specific measurement method.";		specific measurement method.";
	}		}
	}		}
	}		}
	grouping link-jitter-statistics {		grouping link-jitter-statistics {
	description		description
	"Grouping for per link jitter statistics.";		"Grouping for per link jitter statistics.";
	container jitter-statistics {		container jitter-statistics {
	description		description
	"Link jitter summarized information. By default,		"One-way link jitter summarized information.";
	jitter is measured using one-way IP Packet
	Delay Variation (IPDV).";
	reference		reference
	"RFC 3393: IP Packet Delay Variation Metric		"RFC 3393: IP Packet Delay Variation Metric
	for IP Performance Metrics (IPPM)";		for IP Performance Metrics (IPPM)
			RFC 4656: A One-way Active Measurement Protocol (OWAMP)
			ITU-T Y.1731: Operations, administration and
			maintenance (OAM) functions and mechanisms
			for Ethernet-based networks";
	leaf unit-value {		leaf unit-value {
	type identityref {		type identityref {
	base lime:time-unit-type;		base lime:time-unit-type;
	}		}
	default "lime:milliseconds";		default "lime:milliseconds";
	description		description
	"Time units, where the options are s, ms, ns, etc.";		"Time units, where the options are s, ms, ns, etc.";
	}		}
	leaf min-jitter-value {		leaf min-jitter-value {
	type yang:gauge32;		type yang:gauge64;
	description		description
	"Minimum observed one-way jitter.";		"Minimum observed one-way jitter.";
	}		}
	leaf max-jitter-value {		leaf max-jitter-value {
	type yang:gauge32;		type yang:gauge64;
	description		description
	"Maximum observed one-way jitter.";		"Maximum observed one-way jitter.";
	}		}
	leaf low-jitter-percentile {		leaf low-jitter-percentile {
	type yang:gauge32;		type yang:gauge64;
	description		description
	"Low percentile of observed one-way jitter.";		"Low percentile of observed one-way jitter.";
	}		}
	leaf intermediate-jitter-percentile {		leaf intermediate-jitter-percentile {
	type yang:gauge32;		type yang:gauge64;
	description		description
	"Intermediate percentile of observed one-way jitter.";		"Intermediate percentile of observed one-way jitter.";
	}		}
	leaf high-jitter-percentile {		leaf high-jitter-percentile {
	type yang:gauge32;		type yang:gauge64;
	description		description
	"High percentile of observed one-way jitter.";		"High percentile of observed one-way jitter.";
	}		}
	}		}
	}		}
	grouping tp-svc-telemetry {		grouping tp-svc-telemetry {
	leaf reference-time {		leaf reference-time {
	type yang:date-and-time;		type yang:date-and-time;
	config false;		config false;
	description		description
	"Indicates the time when the statistics are collected.";		"Indicates the time when the statistics are collected.";
	}		}
	leaf inbound-octets {		leaf inbound-octets {
	skipping to change at page 22, line 36 ¶		skipping to change at page 22, line 50 ¶
	type yang:counter64;		type yang:counter64;
	description		description
	"The total number of inbound non-unicast		"The total number of inbound non-unicast
	(i.e., broadcast or multicast) packets.";		(i.e., broadcast or multicast) packets.";
	}		}
	leaf inbound-discards {		leaf inbound-discards {
	type yang:counter64;		type yang:counter64;
	description		description
	"The number of inbound packets that were chosen to be		"The number of inbound packets that were chosen to be
	discarded even though no errors had been detected.		discarded even though no errors had been detected.
	One possible reason for discarding such a		Possible reasons for discarding such a packet could
	packet could be to free up buffer space";		be to free up buffer space, not enough buffer for
			too much data, etc.";
	}		}
	leaf inbound-errors {		leaf inbound-errors {
	type yang:counter64;		type yang:counter64;
	description		description
	"The number of inbound packets that contained errors.";		"The number of inbound packets that contained errors.";
	}		}
	leaf inbound-unknown-protocol {		leaf inbound-unknown-protocol {
	type yang:counter64;		type yang:counter64;
	description		description
	"The number of packets received via the interface		"The number of packets received via the interface
	skipping to change at page 23, line 25 ¶		skipping to change at page 23, line 41 ¶
	description		description
	"The total number of outbound non unicast		"The total number of outbound non unicast
	(i.e., broadcast or multicast) packets.";		(i.e., broadcast or multicast) packets.";
	}		}
	leaf outbound-discards {		leaf outbound-discards {
	type yang:counter64;		type yang:counter64;
	description		description
	"The number of outbound packets which were chosen		"The number of outbound packets which were chosen
	to be discarded even though no errors had been		to be discarded even though no errors had been
	detected to prevent their being transmitted.		detected to prevent their being transmitted.
	One possible reason for discarding such a packet could		Possible reasons for discarding such a packet could
	be to free up buffer space.";		be to free up buffer space, not enough buffer for
			too much data, etc.";
	}		}
	leaf outbound-errors {		leaf outbound-errors {
	type yang:counter64;		type yang:counter64;
	description		description
	"The number of outbound packets that contained		"The number of outbound packets that contained
	errors.";		errors.";
	}		}
	description		description
	"Grouping for interface service telemetry.";		"Grouping for interface service telemetry.";
	}		}
	skipping to change at page 30, line 46 ¶		skipping to change at page 31, line 25 ¶
	Email: liuc131@chinaunicom.cn		Email: liuc131@chinaunicom.cn
	Honglei Xu		Honglei Xu
	China Telecom		China Telecom
	Email: xuhl.bri@chinatelecom.cn		Email: xuhl.bri@chinatelecom.cn
	10. References		10. References
	10.1. Normative References		10.1. Normative References
			[ITU-T-Y-1731]
			ITU-T, "Operator Ethernet Service Definition", August
			2015, <https://www.itu.int/rec/T-REC-Y.1731/en>.
	[RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay Variation		[RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay Variation
	Metric for IP Performance Metrics (IPPM)", RFC 3393,		Metric for IP Performance Metrics (IPPM)", RFC 3393,
	DOI 10.17487/RFC3393, November 2002,		DOI 10.17487/RFC3393, November 2002,
	<https://www.rfc-editor.org/info/rfc3393>.		<https://www.rfc-editor.org/info/rfc3393>.
	[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,		[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
	DOI 10.17487/RFC3688, January 2004,		DOI 10.17487/RFC3688, January 2004,
	<https://www.rfc-editor.org/info/rfc3688>.		<https://www.rfc-editor.org/info/rfc3688>.
			[RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M.
			Zekauskas, "A One-way Active Measurement Protocol
			(OWAMP)", RFC 4656, DOI 10.17487/RFC4656, September 2006,
			<https://www.rfc-editor.org/info/rfc4656>.
			[RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J.
			Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)",
			RFC 5357, DOI 10.17487/RFC5357, October 2008,
			<https://www.rfc-editor.org/info/rfc5357>.
	[RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for		[RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for
	the Network Configuration Protocol (NETCONF)", RFC 6020,		the Network Configuration Protocol (NETCONF)", RFC 6020,
	DOI 10.17487/RFC6020, October 2010,		DOI 10.17487/RFC6020, October 2010,
	<https://www.rfc-editor.org/info/rfc6020>.		<https://www.rfc-editor.org/info/rfc6020>.
	[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 32, line 42 ¶		skipping to change at page 33, line 35 ¶
	Barguil, S., Dios, O. G. D., Boucadair, M., and L. A.		Barguil, S., Dios, O. G. D., Boucadair, M., and L. A.
	Munoz, "A Layer 2 VPN Network YANG Model", Work in		Munoz, "A Layer 2 VPN Network YANG Model", Work in
	Progress, Internet-Draft, draft-ietf-opsawg-l2nm-12, 22		Progress, Internet-Draft, draft-ietf-opsawg-l2nm-12, 22
	November 2021, <https://www.ietf.org/archive/id/draft-		November 2021, <https://www.ietf.org/archive/id/draft-
	ietf-opsawg-l2nm-12.txt>.		ietf-opsawg-l2nm-12.txt>.
	[I-D.ietf-opsawg-sap]		[I-D.ietf-opsawg-sap]
	Boucadair, M., Dios, O. G. D., Barguil, S., Wu, Q., and V.		Boucadair, M., Dios, O. G. D., Barguil, S., Wu, Q., and V.
	Lopez, "A Network YANG Model for Service Attachment Points		Lopez, "A Network YANG Model for Service Attachment Points
	(SAPs)", Work in Progress, Internet-Draft, draft-ietf-		(SAPs)", Work in Progress, Internet-Draft, draft-ietf-
	opsawg-sap-02, 22 February 2022,		opsawg-sap-03, 21 March 2022,
	<https://www.ietf.org/archive/id/draft-ietf-opsawg-sap-		<https://www.ietf.org/archive/id/draft-ietf-opsawg-sap-
	02.txt>.		03.txt>.
	[ITU-T-Y-1731]		[RFC4026] Andersson, L. and T. Madsen, "Provider Provisioned Virtual
	ITU-T, "Operator Ethernet Service Definition", August		Private Network (VPN) Terminology", RFC 4026,
	2015, <https://www.itu.int/rec/T-REC-Y.1731/en>.		DOI 10.17487/RFC4026, March 2005,
			<https://www.rfc-editor.org/info/rfc4026>.
	[RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M.		[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
	Zekauskas, "A One-way Active Measurement Protocol		Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February
	(OWAMP)", RFC 4656, DOI 10.17487/RFC4656, September 2006,		2006, <https://www.rfc-editor.org/info/rfc4364>.
	<https://www.rfc-editor.org/info/rfc4656>.
	[RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J.		[RFC5277] Chisholm, S. and H. Trevino, "NETCONF Event
	Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)",		Notifications", RFC 5277, DOI 10.17487/RFC5277, July 2008,
	RFC 5357, DOI 10.17487/RFC5357, October 2008,		<https://www.rfc-editor.org/info/rfc5277>.
	<https://www.rfc-editor.org/info/rfc5357>.
	[RFC7471] Giacalone, S., Ward, D., Drake, J., Atlas, A., and S.		[RFC7471] Giacalone, S., Ward, D., Drake, J., Atlas, A., and S.
	Previdi, "OSPF Traffic Engineering (TE) Metric		Previdi, "OSPF Traffic Engineering (TE) Metric
	Extensions", RFC 7471, DOI 10.17487/RFC7471, March 2015,		Extensions", RFC 7471, DOI 10.17487/RFC7471, March 2015,
	<https://www.rfc-editor.org/info/rfc7471>.		<https://www.rfc-editor.org/info/rfc7471>.
	[RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF		[RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
	Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,		Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
	<https://www.rfc-editor.org/info/rfc8040>.		<https://www.rfc-editor.org/info/rfc8040>.
	skipping to change at page 33, line 43 ¶		skipping to change at page 34, line 33 ¶
	D., Drake, J., and Q. Wu, "IS-IS Traffic Engineering (TE)		D., Drake, J., and Q. Wu, "IS-IS Traffic Engineering (TE)
	Metric Extensions", RFC 8570, DOI 10.17487/RFC8570, March		Metric Extensions", RFC 8570, DOI 10.17487/RFC8570, March
	2019, <https://www.rfc-editor.org/info/rfc8570>.		2019, <https://www.rfc-editor.org/info/rfc8570>.
	[RFC8571] Ginsberg, L., Ed., Previdi, S., Wu, Q., Tantsura, J., and		[RFC8571] Ginsberg, L., Ed., Previdi, S., Wu, Q., Tantsura, J., and
	C. Filsfils, "BGP - Link State (BGP-LS) Advertisement of		C. Filsfils, "BGP - Link State (BGP-LS) Advertisement of
	IGP Traffic Engineering Performance Metric Extensions",		IGP Traffic Engineering Performance Metric Extensions",
	RFC 8571, DOI 10.17487/RFC8571, March 2019,		RFC 8571, DOI 10.17487/RFC8571, March 2019,
	<https://www.rfc-editor.org/info/rfc8571>.		<https://www.rfc-editor.org/info/rfc8571>.
			[RFC8632] Vallin, S. and M. Bjorklund, "A YANG Data Model for Alarm
			Management", RFC 8632, DOI 10.17487/RFC8632, September
			2019, <https://www.rfc-editor.org/info/rfc8632>.
			[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>.
	[RFC8969] Wu, Q., Ed., Boucadair, M., Ed., Lopez, D., Xie, C., and		[RFC8969] Wu, Q., Ed., Boucadair, M., Ed., Lopez, D., Xie, C., and
	L. Geng, "A Framework for Automating Service and Network		L. Geng, "A Framework for Automating Service and Network
	Management with YANG", RFC 8969, DOI 10.17487/RFC8969,		Management with YANG", RFC 8969, DOI 10.17487/RFC8969,
	January 2021, <https://www.rfc-editor.org/info/rfc8969>.		January 2021, <https://www.rfc-editor.org/info/rfc8969>.
	[RFC9182] Barguil, S., Gonzalez de Dios, O., Ed., Boucadair, M.,		[RFC9182] Barguil, S., Gonzalez de Dios, O., Ed., Boucadair, M.,
	Ed., Munoz, L., and A. Aguado, "A YANG Network Data Model		Ed., Munoz, L., and A. Aguado, "A YANG Network Data Model
	for Layer 3 VPNs", RFC 9182, DOI 10.17487/RFC9182,		for Layer 3 VPNs", RFC 9182, DOI 10.17487/RFC9182,
	February 2022, <https://www.rfc-editor.org/info/rfc9182>.		February 2022, <https://www.rfc-editor.org/info/rfc9182>.
End of changes. 38 change blocks.
	68 lines changed or deleted		104 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/