rfc9630v1.txt		rfc9630.txt
	skipping to change at line 69 ¶		skipping to change at line 69 ¶
	1. Introduction		1. Introduction
	1.1. Requirements Language		1.1. Requirements Language
	2. Requirements for Multicast Traffic Telemetry		2. Requirements for Multicast Traffic Telemetry
	3. Issues of Existing Techniques		3. Issues of Existing Techniques
	4. Modifications and Extensions Based on Existing Solutions		4. Modifications and Extensions Based on Existing Solutions
	4.1. Per-Hop Postcard Using IOAM DEX		4.1. Per-Hop Postcard Using IOAM DEX
	4.2. Per-Section Postcard for IOAM Trace		4.2. Per-Section Postcard for IOAM Trace
	5. Application Considerations for Multicast Protocols		5. Application Considerations for Multicast Protocols
	5.1. Mtrace Version 2		5.1. Mtrace Version 2
	5.2. Application in PIM		5.2. Application in PIM
	5.3. Application of MVPN X-PMSI Tunnel Encapsulation Attribute		5.3. Application of MVPN PMSI Tunnel Attribute
	6. Security Considerations		6. Security Considerations
	7. IANA Considerations		7. IANA Considerations
	8. References		8. References
	8.1. Normative References		8.1. Normative References
	8.2. Informative References		8.2. Informative References
	Acknowledgments		Acknowledgments
	Authors' Addresses		Authors' Addresses
	1. Introduction		1. Introduction
	skipping to change at line 111 ¶		skipping to change at line 111 ¶
	It is essential to monitor the performance of multicast traffic. New		It is essential to monitor the performance of multicast traffic. New
	on-path telemetry techniques, such as IOAM [RFC9197], IOAM Direct		on-path telemetry techniques, such as IOAM [RFC9197], IOAM Direct
	Export (DEX) [RFC9326], IOAM Postkcard-Based Telemetry - Marking		Export (DEX) [RFC9326], IOAM Postkcard-Based Telemetry - Marking
	(PBT-M) [POSTCARD-TELEMETRY], and Hybrid Two-Step (HTS)		(PBT-M) [POSTCARD-TELEMETRY], and Hybrid Two-Step (HTS)
	[HYBRID-TWO-STEP], complement existing active OAM performance		[HYBRID-TWO-STEP], complement existing active OAM performance
	monitoring methods like ICMP ping [RFC0792]. However, multicast		monitoring methods like ICMP ping [RFC0792]. However, multicast
	traffic's unique characteristics present challenges in applying these		traffic's unique characteristics present challenges in applying these
	techniques efficiently.		techniques efficiently.
	The IP multicast packet data for a particular (S, G) state remains		The IP multicast packet data for a particular (S,G) state remains
	identical across different branches to multiple receivers. When IOAM		identical across different branches to multiple receivers [RFC4601].
	trace data is added to multicast packets, each replicated packet		When IOAM trace data is added to multicast packets, each replicated
	retains telemetry data for its entire forwarding path. This results		packet retains telemetry data for its entire forwarding path. This
	in redundant data collection for common path segments, unnecessarily		results in redundant data collection for common path segments,
	consuming extra network bandwidth. For large multicast trees, this		unnecessarily consuming extra network bandwidth. For large multicast
	redundancy is substantial. Using solutions like IOAM DEX could be		trees, this redundancy is substantial. Using solutions like IOAM DEX
	more efficient by eliminating data redundancy, but IOAM DEX lacks a		could be more efficient by eliminating data redundancy, but IOAM DEX
	branch identifier, complicating telemetry data correlation and		lacks a branch identifier, complicating telemetry data correlation
	multicast tree reconstruction.		and multicast tree reconstruction.
	This document provides two solutions to the IOAM data-redundancy		This document provides two solutions to the IOAM data-redundancy
	problem based on the IOAM standards. The requirements for multicast		problem based on the IOAM standards. The requirements for multicast
	traffic telemetry are discussed along with the issues of the existing		traffic telemetry are discussed along with the issues of the existing
	on-path telemetry techniques. We propose modifications and		on-path telemetry techniques. We propose modifications and
	extensions to make these techniques adapt to multicast in order for		extensions to make these techniques adapt to multicast in order for
	the original multicast tree to be correctly reconstructed while		the original multicast tree to be correctly reconstructed while
	eliminating redundant data. This document does not cover the		eliminating redundant data. This document does not cover the
	operational considerations such as how to enable the telemetry on a		operational considerations such as how to enable the telemetry on a
	subset of the traffic to avoid overloading the network or the data		subset of the traffic to avoid overloading the network or the data
	skipping to change at line 405 ¶		skipping to change at line 405 ¶
	forward multicast UDP data packets. PIM utilizes network-based		forward multicast UDP data packets. PIM utilizes network-based
	source discovery. PIM-SSM, however, utilizes application-based		source discovery. PIM-SSM, however, utilizes application-based
	source discovery. IP multicast packets fall within the range of		source discovery. IP multicast packets fall within the range of
	224.0.0.0 through 239.255.255.255 for IPv4 and ff00::/8 for IPv6.		224.0.0.0 through 239.255.255.255 for IPv4 and ff00::/8 for IPv6.
	The telemetry solution will need to work within these IP address		The telemetry solution will need to work within these IP address
	ranges and provide telemetry data for this UDP traffic.		ranges and provide telemetry data for this UDP traffic.
	A proposed solution for encapsulating the telemetry instruction		A proposed solution for encapsulating the telemetry instruction
	header and metadata in IPv6 packets is described in [RFC9486].		header and metadata in IPv6 packets is described in [RFC9486].
	5.3. Application of MVPN X-PMSI Tunnel Encapsulation Attribute		5.3. Application of MVPN PMSI Tunnel Attribute
	IOAM, and the recommendations of this document, are equally		IOAM, and the recommendations of this document, are equally
	applicable to multicast MPLS forwarded packets. Multipoint Label		applicable to multicast MPLS forwarded packets as described in
	Distribution Protocol (mLDP), P2MP RSVP-TE, Ingress Replication (IR),		[RFC6514]. Multipoint Label Distribution Protocol (mLDP), P2MP RSVP-
	and PIM Multicast Distribution Tree (MDT) SAFI with GRE Transport are		TE, Ingress Replication (IR), and PIM Multicast Distribution Tree
	all commonly used within a Multicast VPN (MVPN) environment utilizing		(MDT) SAFI with GRE Transport are all commonly used within a
	MVPN procedures such as multicast in MPLS/BGP IP VPNs [RFC6513] and		Multicast VPN (MVPN) environment utilizing MVPN procedures such as
	BGP encoding and procedures for multicast in MPLS/BGP IP VPNs		multicast in MPLS/BGP IP VPNs [RFC6513] and BGP encoding and
	[RFC6514]. mLDP LDP extensions for P2MP and multipoint-to-multipoint		procedures for multicast in MPLS/BGP IP VPNs [RFC6514]. mLDP LDP
	(MP2MP) label switched paths (LSPs) [RFC6388] provide extensions to		extensions for P2MP and multipoint-to-multipoint (MP2MP) label
	LDP to establish point-to-multipoint (P2MP) and MP2MP LSPs in MPLS		switched paths (LSPs) [RFC6388] provide extensions to LDP to
	networks. The telemetry solution will need to be able to follow		establish point-to-multipoint (P2MP) and MP2MP LSPs in MPLS networks.
	these P2MP and MP2MP paths. The telemetry instruction header and		The telemetry solution will need to be able to follow these P2MP and
	data should be encapsulated into MPLS packets on P2MP and MP2MP		MP2MP paths. The telemetry instruction header and data should be
	paths.		encapsulated into MPLS packets on P2MP and MP2MP paths.
	6. Security Considerations		6. Security Considerations
	The schemes discussed in this document share the same security		The schemes discussed in this document share the same security
	considerations for the IOAM trace option [RFC9197] and the IOAM DEX		considerations for the IOAM trace option [RFC9197] and the IOAM DEX
	option [RFC9326]. In particular, since multicast has a built-in		option [RFC9326]. In particular, since multicast has a built-in
	nature for packet amplification, the possible amplification risk for		nature for packet amplification, the possible amplification risk for
	the DEX-based scheme is greater than the case of unicast. Hence,		the DEX-based scheme is greater than the case of unicast. Hence,
	stricter mechanisms for protections need to be applied. In addition		stricter mechanisms for protections need to be applied. In addition
	to selecting packets to enable DEX and to limit the exported traffic		to selecting packets to enable DEX and to limit the exported traffic
	skipping to change at line 540 ¶		skipping to change at line 540 ¶
	[RFC0792] Postel, J., "Internet Control Message Protocol", STD 5,		[RFC0792] Postel, J., "Internet Control Message Protocol", STD 5,
	RFC 792, DOI 10.17487/RFC0792, September 1981,		RFC 792, DOI 10.17487/RFC0792, September 1981,
	<https://www.rfc-editor.org/info/rfc792>.		<https://www.rfc-editor.org/info/rfc792>.
	[RFC3605] Huitema, C., "Real Time Control Protocol (RTCP) attribute		[RFC3605] Huitema, C., "Real Time Control Protocol (RTCP) attribute
	in Session Description Protocol (SDP)", RFC 3605,		in Session Description Protocol (SDP)", RFC 3605,
	DOI 10.17487/RFC3605, October 2003,		DOI 10.17487/RFC3605, October 2003,
	<https://www.rfc-editor.org/info/rfc3605>.		<https://www.rfc-editor.org/info/rfc3605>.
			[RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas,
			"Protocol Independent Multicast - Sparse Mode (PIM-SM):
			Protocol Specification (Revised)", RFC 4601,
			DOI 10.17487/RFC4601, August 2006,
			<https://www.rfc-editor.org/info/rfc4601>.
	[RFC6450] Venaas, S., "Multicast Ping Protocol", RFC 6450,		[RFC6450] Venaas, S., "Multicast Ping Protocol", RFC 6450,
	DOI 10.17487/RFC6450, December 2011,		DOI 10.17487/RFC6450, December 2011,
	<https://www.rfc-editor.org/info/rfc6450>.		<https://www.rfc-editor.org/info/rfc6450>.
	[RFC8487] Asaeda, H., Meyer, K., and W. Lee, Ed., "Mtrace Version 2:		[RFC8487] Asaeda, H., Meyer, K., and W. Lee, Ed., "Mtrace Version 2:
	Traceroute Facility for IP Multicast", RFC 8487,		Traceroute Facility for IP Multicast", RFC 8487,
	DOI 10.17487/RFC8487, October 2018,		DOI 10.17487/RFC8487, October 2018,
	<https://www.rfc-editor.org/info/rfc8487>.		<https://www.rfc-editor.org/info/rfc8487>.
	[RFC9486] Bhandari, S., Ed. and F. Brockners, Ed., "IPv6 Options for		[RFC9486] Bhandari, S., Ed. and F. Brockners, Ed., "IPv6 Options for
End of changes. 5 change blocks.
	25 lines changed or deleted		31 lines changed or added
This html diff was produced by rfcdiff 1.48.