< draft-ietf-mboned-multicast-telemetry-00.txt		draft-ietf-mboned-multicast-telemetry-01.txt >
	MBONED H. Song		MBONED H. Song
	Internet-Draft M. McBride		Internet-Draft M. McBride
	Intended status: Standards Track Futurewei Technologies		Intended status: Standards Track Futurewei Technologies
	Expires: August 26, 2021 G. Mirsky		Expires: January 7, 2022 G. Mirsky
	ZTE Corp.		ZTE Corp.
	G. Mishra		G. Mishra
	Verizon Inc.		Verizon Inc.
	H. Asaeda		H. Asaeda
	NICT		NICT
	T. Zhou		T. Zhou
	Huawei		Huawei
	February 22, 2021		July 6, 2021
	Multicast On-path Telemetry Solutions		Multicast On-path Telemetry Solutions
	draft-ietf-mboned-multicast-telemetry-00		draft-ietf-mboned-multicast-telemetry-01
	Abstract		Abstract
	This document discusses the requirement of on-path telemetry for		This document discusses the requirement of on-path telemetry for
	multicast traffic. The existing solutions are examined and their		multicast traffic. The existing solutions are examined and their
	issues are identified. Solution modifications are proposed to allow		issues are identified. Solution modifications are proposed to allow
	the original multicast tree to be correctly reconstructed without		the original multicast tree to be correctly reconstructed without
	unnecessary replication of telemetry information.		unnecessary replication of telemetry information.
	Requirements Language		Requirements Language
	skipping to change at page 2, line 4 ¶		skipping to change at page 2, line 4 ¶
	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 August 26, 2021.		This Internet-Draft will expire on January 7, 2022.
	Copyright Notice		Copyright Notice
	Copyright (c) 2021 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
	skipping to change at page 2, line 26 ¶		skipping to change at page 2, line 26 ¶
	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
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	2. Requirements for Multicast Traffic Telemetry . . . . . . . . 3		2. Requirements for Multicast Traffic Telemetry . . . . . . . . 3
	3. Issues of Existing Techniques . . . . . . . . . . . . . . . . 4		3. Issues of Existing Techniques . . . . . . . . . . . . . . . . 4
	4. Proposed Modifications to Existing Techniques . . . . . . . . 4		4. Proposed Modifications to Existing Techniques . . . . . . . . 5
	4.1. Per-hop postcard using IOAM DEX . . . . . . . . . . . . . 5		4.1. Per-hop postcard using IOAM DEX . . . . . . . . . . . . . 5
	4.2. Per-section postcard . . . . . . . . . . . . . . . . . . 7		4.2. Per-section postcard . . . . . . . . . . . . . . . . . . 7
	5. Considerations for Different Multicast Protocols . . . . . . 8		5. Considerations for Different Multicast Protocols . . . . . . 8
	5.1. Application in PIM . . . . . . . . . . . . . . . . . . . 8		5.1. Application in PIM . . . . . . . . . . . . . . . . . . . 8
	5.2. Application in P2MP . . . . . . . . . . . . . . . . . . . 9		5.2. Application of MVPN X-PMSI Tunnel Encapsulation Attribute 9
	5.3. Application in BIER . . . . . . . . . . . . . . . . . . . 9		5.3. Application in BIER . . . . . . . . . . . . . . . . . . . 9
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 10		6. Security Considerations . . . . . . . . . . . . . . . . . . . 10
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
	8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 10		8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 10
	9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10		9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10
	10. References . . . . . . . . . . . . . . . . . . . . . . . . . 10		10. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
	10.1. Normative References . . . . . . . . . . . . . . . . . . 10		10.1. Normative References . . . . . . . . . . . . . . . . . . 10
	10.2. Informative References . . . . . . . . . . . . . . . . . 11		10.2. Informative References . . . . . . . . . . . . . . . . . 12
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
	1. Introduction		1. Introduction
	Multicast traffic is an important traffic type in today's Internet.		Multicast traffic is used across operator networks to support
	Multicast provides services that are often real time (e.g., online		residential broadband customers, private MPLS customers and used with
	meeting) or have strict QoS requirements (e.g., IPTV, Market Data).		corporate intranet internal customers. Multicast provides real time
	Multicast packet drop and delay can severely affect the application		interactive online meetings or podcasts, IPTV and financial markets
	performance and user experience.		real-time data, which all have a reliance on UDP's unreliable
			transport. End to end QOS, therefore, should be a critical component
			of multicast deployment in order to provide a good end user viewing
			experience. If a packet is dropped, and that packet happens to be a
			reference frame (I-Frame) in the video feed, the client receiver of
			the multicast feed goes into buffering mode resulting in a frozen
			window. Multicast packet drops and delay can severely affect the
			application performance and user experience.
	It is important to monitor the performance of the multicast traffic.		It is important to monitor the performance of the multicast traffic.
	Existing OAM techniques cannot gain direct and accurate information		New on-path telemetry techniques such as In-situ OAM
	about the multicast traffic. New on-path telemetry techniques such		[I-D.ietf-ippm-ioam-data], Postcard-based Telemetry
	as In-situ OAM [I-D.ietf-ippm-ioam-data], Postcard-based Telemetry
	[I-D.song-ippm-postcard-based-telemetry], and Hybrid Two-Step (HTS)		[I-D.song-ippm-postcard-based-telemetry], and Hybrid Two-Step (HTS)
	[I-D.mirsky-ippm-hybrid-two-step] provide promising means to directly		[I-D.mirsky-ippm-hybrid-two-step] are useful and complementary to the
	monitor the network experience of multicast traffic. However,		existing active OAM performance monitoring methods, provide promising
	multicast traffic has some unique characteristics which pose some		means to directly monitor the network experience of multicast
	challenges on efficiently applying such techniques.		traffic. However, multicast traffic has some unique characteristics
			which pose some challenges on efficiently applying such techniques.
	When a network contains multicast (p2mp) trees there will be		The IP Multicast S,G data is identical from one branch to another on
	redundant data as data is replicated at branch points. The IP		it's way to multiple receivers. When adding iOAM trace data, to
	Multicast S,G data is identical from one branch to another on it's		multicast packets, we enlarge data packets thus consuming more
	way to multiple receivers. When adding iOAM trace data, to multicast		network bandwidth. Instead of adding iOAM trace data, it could be
	packets, we enlarge data packets thus consuming more network		more efficient to collect the telemetry information using solutions,
	bandwidth. Instead of adding iOAM trace data, it could be more		such as iOAM postcard or HTS, to cut down on the redundant iOAM data.
	efficient to collect the telemetry information using solutions, such		The problem is that a postcard type solution doesn't have a branch
	as iOAM postcard or HTS, to cut down on the redundant iOAM data. The
	problem is that a postcard type solution doesn't have a branch
	identifier.		identifier.
	This draft proposes a set of solutions to this iOAM data redundancy		This draft proposes a set of solutions to this iOAM data redundancy
	problem. The requirements for multicast traffic telemetry are		problem. The requirements for multicast traffic telemetry are
	discussed along with the issues of the existing on-path telemetry		discussed along with the issues of the existing on-path telemetry
	techniques. We propose modifications to make these techniques adapt		techniques. We propose modifications to make these techniques adapt
	to multicast in order for the original multicast tree to be correctly		to multicast in order for the original multicast tree to be correctly
	reconstructed while eliminating redundant data.		reconstructed while eliminating redundant data.
	2. Requirements for Multicast Traffic Telemetry		2. Requirements for Multicast Traffic Telemetry
	skipping to change at page 5, line 43 ¶		skipping to change at page 6, line 5 ¶
	| | | |----+ : +---+		| | | |----+ : +---+
	| A |------->| B | :		| A |------->| B | :
	| | | |--+ +-:-+		| | | |--+ +-:-+
	+---+ +---+ | | |		+---+ +---+ | | |
	+-->| D |--....		+-->| D |--....
	| |		| |
	+---+		+---+
	Figure 1: Per-hop Postcard		Figure 1: Per-hop Postcard
	Each branch fork node need to generate the branch ID for each branch		Each branch fork node needs to generate the branch ID for each branch
	in its multicast tree instance and include it in the IOAM DEX option		in its multicast tree instance and include it in the IOAM DEX option
	header so the downstream node can learn it. The branch ID contains		header so the downstream node can learn it. The branch ID contains
	two parts: the branch fork node ID and a unique branch index.		two parts: the branch fork node ID and a unique branch index.
	Figure 2 shows that the branch ID is carried as an optional field		Figure 2 shows that the branch ID is carried as an optional field
	after the flow ID and sequence number optional fields in the IOAM DEX		after the flow ID and sequence number optional fields in the IOAM DEX
	option header. A bit "M" in the Flags field is reserved to indicate		option header. A bit "M" in the Flags field is reserved to indicate
	the presence of the branch index field. The "M" flag position will		the presence of the branch index field. The "M" flag position will
	be determined later after the other flags are specified in		be determined later after the other flags are specified in
	[I-D.ioamteam-ippm-ioam-direct-export].		[I-D.ioamteam-ippm-ioam-direct-export].
	skipping to change at page 8, line 48 ¶		skipping to change at page 8, line 48 ¶
	multicast data. Each will require their own unique on-path telemetry		multicast data. Each will require their own unique on-path telemetry
	solution.		solution.
	5.1. Application in PIM		5.1. Application in PIM
	PIM-SM [RFC7761] is the most widely used multicast routing protocol		PIM-SM [RFC7761] is the most widely used multicast routing protocol
	deployed today. Of the various PIM modes (PIM-SM, PIM-DM, BIDIR-PIM,		deployed today. Of the various PIM modes (PIM-SM, PIM-DM, BIDIR-PIM,
	PIM-SSM), PIM-SSM is the preferred method due to its simplicity and		PIM-SSM), PIM-SSM is the preferred method due to its simplicity and
	removal of network source discovery complexity. With all PIM modes,		removal of network source discovery complexity. With all PIM modes,
	control plane state is established in the network in order to forward		control plane state is established in the network in order to forward
	multicast UDP data packets. But with PIM-SSM, the discovery of		multicast UDP data packets. All PIM modes utilize network based
	multicast sources is performed outside of the network via HTTP, SDN,		source discovery except for PIM-SSM, which utilizes application based
	etc. IP Multicast packets fall within the range of 224.0.0.0 through		source discovery. IP Multicast packets fall within the range of
	239.255.255.255. The telemetry solution will need to work within		224.0.0.0 through 239.255.255.255. The telemetry solution will need
	this address range and provide telemetry data for this UDP traffic.		to work within this address range and provide telemetry data for this
			UDP traffic.
	The proposed solutions for encapsulating the telemetry instruction		The proposed solutions for encapsulating the telemetry instruction
	header and metadata in IPv4/IPv6 UDP packets are described in		header and metadata in IPv4/IPv6 UDP packets are described in
	[I-D.herbert-ipv4-udpencap-eh] and		[I-D.herbert-ipv4-udpencap-eh] and
	[I-D.ioametal-ippm-6man-ioam-ipv6-deployment].		[I-D.ioametal-ippm-6man-ioam-ipv6-deployment].
	5.2. Application in P2MP		5.2. Application of MVPN X-PMSI Tunnel Encapsulation Attribute
	Multicast Label Distribution Protocol (MLDP) and P2MP RSVP-TE are		Multipoint Label Distribution Protocol (mLDP), P2MP RSVP-TE, Ingress
	commonly used within a Multicast VPN (MVPN) environment. MLDP		Replication (IR), PIM MDT SAFI with GRE Transport, are commonly used
	provides extensions to LDP to establish point-to-multipoint (P2MP)		within a Multicast VPN (MVPN) environment utilizing MVPN procedures
	and multipoint-to-multipoint (MP2MP) label switched paths (LSPs) in		Multicast in MPLS/BGP IP VPNs [RFC6513] and BGP Encoding and
	MPLS networks. P2MP RSVP-TE provides extensions to RSVP-TE for		Procedures for Multicast in MPLS/BGP IP VPNs [RFC6514]. MLDP LDP
	establish traffic-engineered P2MP LSPs in MPLS networks. The		Extension for P2MP and MP2MP LSPs [RFC6388] provides extensions to
	telemetry solution will need to be able to follow these P2MP paths.		LDP to establish point-to-multipoint (P2MP) and multipoint-to-
	The telemetry instruction header and data should be encapsulated into		multipoint (MP2MP) label switched paths (LSPs) in MPLS networks.
	MPLS packets on P2MP paths. A corresponding proposal is described in		P2MP RSVP-TE provides extensions to RSVP-TE RSVP-TE for P2MP LSPs
			[RFC4875] for establish traffic-engineered P2MP LSPs in MPLS
			networks. Ingress Replication (IR) P2MP Trees Ingress Replication
			Tunnels in Multicast VPNs [RFC7988] using unicast replication from
			parent node to child node over MPLS Unicast Tunnel. PIM MDT SAFI
			Multicast in BGP/MPLS IP VPNs [RFC6037]utilizes PIM modes PIM-SSM,
			PIM-SM, PIM-BIDIR control plane with GRE transport data plane in the
			core for X-PMSI P-Tree using MVPN procedures. Replication SID SR
			Replication Segment for Multi-point Service Delivery
			[I-D.ietf-spring-sr-replication-segment] replication segments for
			P2MP multicast service delivery in Segment Routing SR-MPLS networks.
			The telemetry solution will need to be able to follow these P2MP and
			MP2MP paths. The telemetry instruction header and data should be
			encapsulated into MPLS packets on P2MP and MP2MP paths. A
			corresponding proposal is described in
	[I-D.song-mpls-extension-header].		[I-D.song-mpls-extension-header].
	5.3. Application in BIER		5.3. Application in BIER
	BIER [RFC8279] adds a new header to multicast packets and allows the		BIER [RFC8279] adds a new header to multicast packets and allows the
	multicast packets to be forwarded according to the header only. By		multicast packets to be forwarded according to the header only. By
	eliminating the requirement of maintaining per multicast group state,		eliminating the requirement of maintaining per multicast group state,
	BIER is more scalable than the traditional multicast solutions.		BIER is more scalable than the traditional multicast solutions.
	OAM Requirements for BIER [I-D.ietf-bier-oam-requirements] lists many		OAM Requirements for BIER [I-D.ietf-bier-oam-requirements] lists many
	skipping to change at page 10, line 8 ¶		skipping to change at page 10, line 18 ¶
	Depending on how the BIER header is encapsulated into packets with		Depending on how the BIER header is encapsulated into packets with
	different transport protocols, the method to encapsulate the		different transport protocols, the method to encapsulate the
	telemetry instruction header and metadata also varies. It is also		telemetry instruction header and metadata also varies. It is also
	possible to make the instruction header and metadata a part of the		possible to make the instruction header and metadata a part of the
	BIER header itself, such as in a TLV.		BIER header itself, such as in a TLV.
	6. Security Considerations		6. Security Considerations
	No new security issues are identified other than those discovered by		No new security issues are identified other than those discovered by
	the IOAM and PBT drafts.		the IOAM, PBT and HTS drafts.
	7. IANA Considerations		7. IANA Considerations
	The document makes no request of IANA.		The document makes no request of IANA.
	8. Contributors		8. Contributors
	TBD		TBD
	9. Acknowledgments		9. Acknowledgments
	skipping to change at page 10, line 38 ¶		skipping to change at page 11, line 5 ¶
	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>.
	[RFC4687] Yasukawa, S., Farrel, A., King, D., and T. Nadeau,		[RFC4687] Yasukawa, S., Farrel, A., King, D., and T. Nadeau,
	"Operations and Management (OAM) Requirements for Point-		"Operations and Management (OAM) Requirements for Point-
	to-Multipoint MPLS Networks", RFC 4687,		to-Multipoint MPLS Networks", RFC 4687,
	DOI 10.17487/RFC4687, September 2006,		DOI 10.17487/RFC4687, September 2006,
	<https://www.rfc-editor.org/info/rfc4687>.		<https://www.rfc-editor.org/info/rfc4687>.
			[RFC4875] Aggarwal, R., Ed., Papadimitriou, D., Ed., and S.
			Yasukawa, Ed., "Extensions to Resource Reservation
			Protocol - Traffic Engineering (RSVP-TE) for Point-to-
			Multipoint TE Label Switched Paths (LSPs)", RFC 4875,
			DOI 10.17487/RFC4875, May 2007,
			<https://www.rfc-editor.org/info/rfc4875>.
			[RFC6037] Rosen, E., Ed., Cai, Y., Ed., and IJ. Wijnands, "Cisco
			Systems' Solution for Multicast in BGP/MPLS IP VPNs",
			RFC 6037, DOI 10.17487/RFC6037, October 2010,
			<https://www.rfc-editor.org/info/rfc6037>.
			[RFC6388] Wijnands, IJ., Ed., Minei, I., Ed., Kompella, K., and B.
			Thomas, "Label Distribution Protocol Extensions for Point-
			to-Multipoint and Multipoint-to-Multipoint Label Switched
			Paths", RFC 6388, DOI 10.17487/RFC6388, November 2011,
			<https://www.rfc-editor.org/info/rfc6388>.
			[RFC6513] Rosen, E., Ed. and R. Aggarwal, Ed., "Multicast in MPLS/
			BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513, February
			2012, <https://www.rfc-editor.org/info/rfc6513>.
			[RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP
			Encodings and Procedures for Multicast in MPLS/BGP IP
			VPNs", RFC 6514, DOI 10.17487/RFC6514, February 2012,
			<https://www.rfc-editor.org/info/rfc6514>.
	[RFC7761] Fenner, B., Handley, M., Holbrook, H., Kouvelas, I.,		[RFC7761] Fenner, B., Handley, M., Holbrook, H., Kouvelas, I.,
	Parekh, R., Zhang, Z., and L. Zheng, "Protocol Independent		Parekh, R., Zhang, Z., and L. Zheng, "Protocol Independent
	Multicast - Sparse Mode (PIM-SM): Protocol Specification		Multicast - Sparse Mode (PIM-SM): Protocol Specification
	(Revised)", STD 83, RFC 7761, DOI 10.17487/RFC7761, March		(Revised)", STD 83, RFC 7761, DOI 10.17487/RFC7761, March
	2016, <https://www.rfc-editor.org/info/rfc7761>.		2016, <https://www.rfc-editor.org/info/rfc7761>.
			[RFC7988] Rosen, E., Ed., Subramanian, K., and Z. Zhang, "Ingress
			Replication Tunnels in Multicast VPN", RFC 7988,
			DOI 10.17487/RFC7988, October 2016,
			<https://www.rfc-editor.org/info/rfc7988>.
	[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC		[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
	2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,		2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
	May 2017, <https://www.rfc-editor.org/info/rfc8174>.		May 2017, <https://www.rfc-editor.org/info/rfc8174>.
	[RFC8279] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A.,		[RFC8279] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A.,
	Przygienda, T., and S. Aldrin, "Multicast Using Bit Index		Przygienda, T., and S. Aldrin, "Multicast Using Bit Index
	Explicit Replication (BIER)", RFC 8279,		Explicit Replication (BIER)", RFC 8279,
	DOI 10.17487/RFC8279, November 2017,		DOI 10.17487/RFC8279, November 2017,
	<https://www.rfc-editor.org/info/rfc8279>.		<https://www.rfc-editor.org/info/rfc8279>.
	[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>.
	10.2. Informative References		10.2. Informative References
	[I-D.herbert-ipv4-udpencap-eh]		[I-D.herbert-ipv4-udpencap-eh]
	Herbert, T., "IPv4 Extension Headers and UDP Encapsulated		Herbert, T., "IPv4 Extension Headers and UDP Encapsulated
	Extension Headers", draft-herbert-ipv4-udpencap-eh-01		Extension Headers", draft-herbert-ipv4-udpencap-eh-01
	(work in progress), March 2019.		(work in progress), March 2019.
	[I-D.ietf-bier-oam-requirements]		[I-D.ietf-bier-oam-requirements]
	Mirsky, G., Nainar, N., Chen, M., and S. Pallagatti,		Mirsky, G., Kumar, N., Chen, M., and S. Pallagatti,
	"Operations, Administration and Maintenance (OAM)		"Operations, Administration and Maintenance (OAM)
	Requirements for Bit Index Explicit Replication (BIER)		Requirements for Bit Index Explicit Replication (BIER)
	Layer", draft-ietf-bier-oam-requirements-11 (work in		Layer", draft-ietf-bier-oam-requirements-11 (work in
	progress), November 2020.		progress), November 2020.
	[I-D.ietf-ippm-ioam-data]		[I-D.ietf-ippm-ioam-data]
	Brockners, F., Bhandari, S., and T. Mizrahi, "Data Fields		Brockners, F., Bhandari, S., and T. Mizrahi, "Data Fields
	for In-situ OAM", draft-ietf-ippm-ioam-data-11 (work in		for In-situ OAM", draft-ietf-ippm-ioam-data-12 (work in
	progress), November 2020.		progress), February 2021.
			[I-D.ietf-spring-sr-replication-segment]
			Voyer, D., Filsfils, C., Parekh, R., Bidgoli, H., and Z.
			Zhang, "SR Replication Segment for Multi-point Service
			Delivery", draft-ietf-spring-sr-replication-segment-04
			(work in progress), February 2021.
	[I-D.ioametal-ippm-6man-ioam-ipv6-deployment]		[I-D.ioametal-ippm-6man-ioam-ipv6-deployment]
	Bhandari, S., Brockners, F., Mizrahi, T., Kfir, A., Gafni,		Bhandari, S., Brockners, F., Mizrahi, T., Kfir, A., Gafni,
	B., Spiegel, M., Krishnan, S., and M. Smith, "Deployment		B., Spiegel, M., Krishnan, S., and M. Smith, "Deployment
	Considerations for In-situ OAM with IPv6 Options", draft-		Considerations for In-situ OAM with IPv6 Options", draft-
	ioametal-ippm-6man-ioam-ipv6-deployment-03 (work in		ioametal-ippm-6man-ioam-ipv6-deployment-03 (work in
	progress), March 2020.		progress), March 2020.
	[I-D.ioamteam-ippm-ioam-direct-export]		[I-D.ioamteam-ippm-ioam-direct-export]
	Song, H., Gafni, B., Zhou, T., Li, Z., Brockners, F.,		Song, H., Gafni, B., Zhou, T., Li, Z., Brockners, F.,
	Bhandari, S., Sivakolundu, R., and T. Mizrahi, "In-situ		Bhandari, S., Sivakolundu, R., and T. Mizrahi, "In-situ
	OAM Direct Exporting", draft-ioamteam-ippm-ioam-direct-		OAM Direct Exporting", draft-ioamteam-ippm-ioam-direct-
	export-00 (work in progress), October 2019.		export-00 (work in progress), October 2019.
	[I-D.mirsky-ippm-hybrid-two-step]		[I-D.mirsky-ippm-hybrid-two-step]
	Mirsky, G., Lingqiang, W., Zhui, G., and H. Song, "Hybrid		Mirsky, G., Lingqiang, W., Zhui, G., and H. Song, "Hybrid
	Two-Step Performance Measurement Method", draft-mirsky-		Two-Step Performance Measurement Method", draft-mirsky-
	ippm-hybrid-two-step-07 (work in progress), December 2020.		ippm-hybrid-two-step-09 (work in progress), March 2021.
	[I-D.song-ippm-postcard-based-telemetry]		[I-D.song-ippm-postcard-based-telemetry]
	Song, H., Zhou, T., Li, Z., Mirsky, G., Shin, J., and K.		Song, H., Mirsky, G., Filsfils, C., Abdelsalam, A., Zhou,
	Lee, "Postcard-based On-Path Flow Data Telemetry using		T., Li, Z., Shin, J., and K. Lee, "Postcard-based On-Path
	Packet Marking", draft-song-ippm-postcard-based-		Flow Data Telemetry using Packet Marking", draft-song-
	telemetry-08 (work in progress), October 2020.		ippm-postcard-based-telemetry-09 (work in progress),
			February 2021.
	[I-D.song-mpls-extension-header]		[I-D.song-mpls-extension-header]
	Song, H., Li, Z., Zhou, T., and L. Andersson, "MPLS		Song, H., Li, Z., Zhou, T., and L. Andersson, "MPLS
	Extension Header", draft-song-mpls-extension-header-02		Extension Header", draft-song-mpls-extension-header-04
	(work in progress), February 2019.		(work in progress), April 2021.
	[I-D.xie-bier-ipv6-encapsulation]		[I-D.xie-bier-ipv6-encapsulation]
	Xie, J., Geng, L., McBride, M., Asati, R., Dhanaraj, S.,		Xie, J., Geng, L., McBride, M., Asati, R., Dhanaraj, S.,
	Zhu, Y., Qin, Z., Shin, M., Mishra, G., and X. Geng,		Zhu, Y., Qin, Z., Shin, M., Mishra, G., and X. Geng,
	"Encapsulation for BIER in Non-MPLS IPv6 Networks", draft-		"Encapsulation for BIER in Non-MPLS IPv6 Networks", draft-
	xie-bier-ipv6-encapsulation-09 (work in progress), January		xie-bier-ipv6-encapsulation-10 (work in progress),
	2021.		February 2021.
	Authors' Addresses		Authors' Addresses
	Haoyu Song		Haoyu Song
	Futurewei Technologies		Futurewei Technologies
	2330 Central Expressway		2330 Central Expressway
	Santa Clara		Santa Clara
	USA		USA
	Email: hsong@futurewei.com		Email: hsong@futurewei.com
End of changes. 25 change blocks.
	59 lines changed or deleted		118 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/