< draft-mirsky-mpls-p2mp-bfd-13.txt		draft-mirsky-mpls-p2mp-bfd-14.txt >
	MPLS Working Group G. Mirsky		MPLS Working Group G. Mirsky
	Internet-Draft ZTE Corp.		Internet-Draft Ericsson
	Intended status: Standards Track G. Mishra		Intended status: Standards Track G. Mishra
	Expires: March 11, 2022 Verizon Inc.		Expires: March 11, 2022 Verizon Inc.
	D. Eastlake		D. Eastlake
	Futurewei Technologies		Futurewei Technologies
	September 7, 2021		September 7, 2021
	BFD for Multipoint Networks over Point-to-Multi-Point MPLS LSP		BFD for Multipoint Networks over Point-to-Multi-Point MPLS LSP
	draft-mirsky-mpls-p2mp-bfd-13		draft-mirsky-mpls-p2mp-bfd-14
	Abstract		Abstract
	This document describes procedures for using Bidirectional Forwarding		This document describes procedures for using Bidirectional Forwarding
	Detection (BFD) for multipoint networks to detect data plane failures		Detection (BFD) for multipoint networks to detect data plane failures
	in Multiprotocol Label Switching (MPLS) point-to-multipoint (p2mp)		in Multiprotocol Label Switching (MPLS) point-to-multipoint (p2mp)
	Label Switched Paths (LSPs) using active tails with unsolicited		Label Switched Paths (LSPs).
	notifications mode. It also describes the applicability of LSP Ping,
	as in-band, and the control plane, as out-band, solutions to		It also describes the applicability of LSP Ping, as in-band, and the
	bootstrap a BFD session in this environment.		control plane, as out-band, solutions to bootstrap a BFD session.
			It also describes the behavior of the active tail for head
			notification.
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	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/.
	skipping to change at page 2, line 13 ¶		skipping to change at page 2, line 18 ¶
	publication of this document. Please review these documents		publication of this document. Please review these documents
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	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. Conventions used in this document . . . . . . . . . . . . . . 2		2. Conventions used in this document . . . . . . . . . . . . . . 3
	2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3		2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
	2.2. Requirements Language . . . . . . . . . . . . . . . . . . 3		2.2. Requirements Language . . . . . . . . . . . . . . . . . . 3
	3. Multipoint BFD Encapsulation . . . . . . . . . . . . . . . . 3		3. Multipoint BFD Encapsulation . . . . . . . . . . . . . . . . 3
	3.1. IP Encapsulation of Multipoint BFD . . . . . . . . . . . 4		3.1. IP Encapsulation of Multipoint BFD . . . . . . . . . . . 4
	3.2. Non-IP Encapsulation of Multipoint BFD . . . . . . . . . 4		3.2. Non-IP Encapsulation of Multipoint BFD . . . . . . . . . 4
	4. Bootstrapping Multipoint BFD . . . . . . . . . . . . . . . . 5		4. Bootstrapping Multipoint BFD . . . . . . . . . . . . . . . . 5
	4.1. LSP Ping . . . . . . . . . . . . . . . . . . . . . . . . 5		4.1. LSP Ping . . . . . . . . . . . . . . . . . . . . . . . . 5
	4.2. Operation of Multipoint BFD with Active Tail over P2MP		4.2. Control Plane . . . . . . . . . . . . . . . . . . . . . . 6
	MPLS LSP . . . . . . . . . . . . . . . . . . . . . . . . 6		5. Operation of Multipoint BFD with Active Tail over P2MP MPLS
	4.3. Control Plane . . . . . . . . . . . . . . . . . . . . . . 7		LSP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
	5. Security Considerations . . . . . . . . . . . . . . . . . . . 7		6. Security Considerations . . . . . . . . . . . . . . . . . . . 7
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
	7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8		8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8		9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
	8.1. Normative References . . . . . . . . . . . . . . . . . . 8		9.1. Normative References . . . . . . . . . . . . . . . . . . 8
	8.2. Informative References . . . . . . . . . . . . . . . . . 9		9.2. Informative References . . . . . . . . . . . . . . . . . 9
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
	1. Introduction		1. Introduction
	[RFC8562] defines a method of using Bidirectional Detection (BFD)		[RFC8562] defines a method of using Bidirectional Detection (BFD)
	[RFC5880] to monitor and detect unicast failures between the sender		[RFC5880] to monitor and detect unicast failures between the sender
	(head) and one or more receivers (tails) in multipoint or multicast		(head) and one or more receivers (tails) in multipoint or multicast
	networks. [RFC8562] added two BFD session types - MultipointHead and		networks.
			[RFC8562] added two BFD session types - MultipointHead and
	MultipointTail. Throughout this document, MultipointHead and		MultipointTail. Throughout this document, MultipointHead and
	MultipointTail refer to the value of the bfd.SessionType is set on a		MultipointTail refer to the value of the bfd.SessionType is set on a
	BFD endpoint. This document describes procedures for using such		BFD endpoint.
	modes of BFD protocol to detect data plane failures in Multiprotocol
	Label Switching (MPLS) point-to-multipoint (p2mp) Label Switched		This document describes procedures for using such modes of BFD
	Paths (LSPs). The document also describes the applicability of out-		protocol to detect data plane failures in Multiprotocol Label
	band solutions to bootstrap a BFD session in this environment.		Switching (MPLS) point-to-multipoint (p2mp) Label Switched Paths
			(LSPs).
			The document also describes the applicability of out-band solutions
			to bootstrap a BFD session in this environment.
			It also describes the behavior of the active tail for head
			notification.
	2. Conventions used in this document		2. Conventions used in this document
	2.1. Terminology		2.1. Terminology
	MPLS: Multiprotocol Label Switching		MPLS: Multiprotocol Label Switching
	LSP: Label Switched Path		LSP: Label Switched Path
	BFD: Bidirectional Forwarding Detection		BFD: Bidirectional Forwarding Detection
	p2mp: Point-to-Multipoint		p2mp: Point-to-Multipoint
	skipping to change at page 3, line 41 ¶		skipping to change at page 3, line 50 ¶
	[RFC8562] uses BFD in the Demand mode from the very start of a point-		[RFC8562] uses BFD in the Demand mode from the very start of a point-
	to-multipoint (p2mp) BFD session. Because the head doesn't receive		to-multipoint (p2mp) BFD session. Because the head doesn't receive
	any BFD Control packet from a tail, the head of the p2mp BFD session		any BFD Control packet from a tail, the head of the p2mp BFD session
	transmits all BFD Control packets with the value of Your		transmits all BFD Control packets with the value of Your
	Discriminator field set to zero. As a result, a tail cannot		Discriminator field set to zero. As a result, a tail cannot
	demultiplex BFD sessions using Your Discriminator, as defined in		demultiplex BFD sessions using Your Discriminator, as defined in
	[RFC5880]. [RFC8562] requires that to demultiplex BFD sessions, the		[RFC5880]. [RFC8562] requires that to demultiplex BFD sessions, the
	tail uses the source IP address, My Discriminator, and the identity		tail uses the source IP address, My Discriminator, and the identity
	of the multipoint tree from which the BFD Control packet was		of the multipoint tree from which the BFD Control packet was
	received. The p2mp MPLS LSP label MAY provide the identification of		received. If the BFD Control packet is encapsulated in IP/UDP, then
	the multipoint tree in case of an inclusive p-tree or upstream-		the source IP address MUST be used to demultiplex the received BFD
	assigned label in case of aggregate p-tree. If the BFD Control		Control packet as described in Section 3.1. The non-IP encapsulation
	packet is encapsulated in IP/UDP, then the source IP address MUST be		case is described in Section 3.2.
	used to demultiplex the received BFD Control packet as described in
	Section 3.1. The non-IP encapsulation case is described in
	Section 3.2.
	3.1. IP Encapsulation of Multipoint BFD		3.1. IP Encapsulation of Multipoint BFD
	[RFC8562] defines IP/UDP encapsulation for multipoint BFD over p2mp		[RFC8562] defines IP/UDP encapsulation for multipoint BFD over p2mp
	MPLS LSP:		MPLS LSP:
	UDP destination port MUST be set to 3784;		UDP destination port MUST be set to 3784;
	destination IP address MUST be set to the loopback address		destination IP address MUST be set to the loopback address
	127.0.0.1/32 for IPv4, or the loopback address ::1/128 for IPv6		127.0.0.1/32 for IPv4, or the loopback address ::1/128 for IPv6
	[RFC4291].		[RFC4291]. Note that that is different from how the destination
			IP address selection is defined in Section 7 [RFC5884]. Firstly,
			because only one loopback address ::1/128 is defined in IPv6. And
			also, it is recommended to use the Entropy Label [RFC6790] to
			discover multiple alternate paths in an MPLS network. Using a
			single loopback address both for IPv4 and IPv6 encapsulation makes
			it consistent and more straightforward for an implementation.
	This specification further clarifies that:		This specification further clarifies that:
	if multiple alternative paths for the given p2mp LSP Forwarding		if multiple alternative paths for the given p2mp LSP Forwarding
	Equivalence Class (FEC) exist, the MultipointHead SHOULD use		Equivalence Class (FEC) exist, the MultipointHead SHOULD use
	Entropy Label [RFC6790] used for LSP Ping [RFC8029] to exercise		Entropy Label [RFC6790] used for LSP Ping [RFC8029] to exercise
	those particular alternative paths;		those particular alternative paths;
	or the MultipointHead MAY use the UDP port number as discovered by		or the MultipointHead MAY use the UDP port number as discovered by
	LSP Ping traceroute [RFC8029] as the source UDP port number to		LSP Ping traceroute [RFC8029] as the source UDP port number to
	skipping to change at page 4, line 44 ¶		skipping to change at page 5, line 4 ¶
	BFD. Avoiding unnecessary encapsulation of p2mp BFD over an MPLS LSP		BFD. Avoiding unnecessary encapsulation of p2mp BFD over an MPLS LSP
	improves the accuracy of the correlation of the detected failure and		improves the accuracy of the correlation of the detected failure and
	defect in MPLS LSP. Non-IP encapsulation for multipoint BFD over		defect in MPLS LSP. Non-IP encapsulation for multipoint BFD over
	p2mp MPLS LSP MUST use Generic Associated Channel (G-ACh) Label (GAL)		p2mp MPLS LSP MUST use Generic Associated Channel (G-ACh) Label (GAL)
	(see [RFC5586]) at the bottom of the label stack followed by an		(see [RFC5586]) at the bottom of the label stack followed by an
	Associated Channel Header (ACH). If a BFD Control packet in PW-ACH		Associated Channel Header (ACH). If a BFD Control packet in PW-ACH
	encapsulation (without IP/UDP Headers) is to be used in ACH, an		encapsulation (without IP/UDP Headers) is to be used in ACH, an
	implementation would not be able to verify the identity of the		implementation would not be able to verify the identity of the
	MultipointHead and, as a result, will not properly demultiplex BFD		MultipointHead and, as a result, will not properly demultiplex BFD
	packets. Hence, a new channel type value is needed. The Channel		packets. Hence, a new channel type value is needed. The Channel
	Type field in ACH MUST be set to TBA1 value Section 6. To provide		Type field in ACH MUST be set to TBA1 value Section 7. To provide
	the identity of the MultipointHead for the particular multipoint BFD		the identity of the MultipointHead for the particular multipoint BFD
	session, a Source Address TLV [RFC7212] MUST immediately follow a BFD		session, a Source Address TLV [RFC7212] MUST immediately follow a BFD
	Control message.		Control message.
	4. Bootstrapping Multipoint BFD		4. Bootstrapping Multipoint BFD
	4.1. LSP Ping		4.1. LSP Ping
	LSP Ping is the part of the on-demand OAM toolset used to detect and		LSP Ping is the part of the on-demand OAM toolset used to detect and
	localize defects in the data plane and verify the control plane		localize defects in the data plane and verify the control plane
	skipping to change at page 6, line 5 ¶		skipping to change at page 6, line 5 ¶
	be used to verify the control plane against the data plane		be used to verify the control plane against the data plane
	periodically by checking that the p2mp LSP is mapped to the same FEC		periodically by checking that the p2mp LSP is mapped to the same FEC
	at the MultipointHead and all active MultipointTails. The rate of		at the MultipointHead and all active MultipointTails. The rate of
	generation of these LSP Ping Echo request messages SHOULD be		generation of these LSP Ping Echo request messages SHOULD be
	significantly less than the rate of generation of the BFD Control		significantly less than the rate of generation of the BFD Control
	packets because LSP Ping requires more processing to validate the		packets because LSP Ping requires more processing to validate the
	consistency between the data plane and the control plane. An		consistency between the data plane and the control plane. An
	implementation MAY provide configuration options to control the rate		implementation MAY provide configuration options to control the rate
	of generation of the periodic LSP Ping Echo request messages.		of generation of the periodic LSP Ping Echo request messages.
	4.2. Operation of Multipoint BFD with Active Tail over P2MP MPLS LSP		4.2. Control Plane
			The BGP-BFD Attribute [RFC9026] MAY be used to bootstrap multipoint
			BFD session on a tail.
			5. Operation of Multipoint BFD with Active Tail over P2MP MPLS LSP
	[RFC8562] defined how the BFD Demand mode can be used in multipoint		[RFC8562] defined how the BFD Demand mode can be used in multipoint
	networks. When applied in MPLS, procedures specified in [RFC8562]		networks. When applied in MPLS, procedures specified in [RFC8562]
	allow an egress LSR to detect a failure of the part of the MPLS p2mp		allow an egress LSR to detect a failure of the part of the MPLS p2mp
	LSP from the ingress LSR. The ingress LSR is not aware of the state		LSP from the ingress LSR. The ingress LSR is not aware of the state
	of the p2mp LSP. [RFC8563], using mechanisms defined in [RFC8562],		of the p2mp LSP. [RFC8563], using mechanisms defined in [RFC8562],
	defined an "active tail" behavior. An active tail might notify the		defined an "active tail" behavior. An active tail might notify the
	head of the detected failure and responds to a poll sequence		head of the detected failure and responds to a poll sequence
	initiated by the head. The first method, referred to as Head		initiated by the head. The first method, referred to as Head
	Notification without Polling, is mentioned in Section 5.2.1		Notification without Polling, is mentioned in Section 5.2.1
	skipping to change at page 6, line 48 ¶		skipping to change at page 7, line 4 ¶
	BFD packets in response to the detection of a multipoint path		BFD packets in response to the detection of a multipoint path
	failure" but without the specifics on the information in the packet		failure" but without the specifics on the information in the packet
	and frequency of transmissions. This document defines below the		and frequency of transmissions. This document defines below the
	procedure of an active tail with unsolicited notifications for p2mp		procedure of an active tail with unsolicited notifications for p2mp
	MPLS LSP.		MPLS LSP.
	Upon detecting the failure of the p2mp MPLS LSP, an egress LSR sends		Upon detecting the failure of the p2mp MPLS LSP, an egress LSR sends
	BFD Control packet with the following settings:		BFD Control packet with the following settings:
	o the Poll (P) bit is set;		o the Poll (P) bit is set;
	o the Status (Sta) field set to Down value;		o the Status (Sta) field set to Down value;
	o the Diagnostic (Diag) field set to Control Detection Time Expired		o the Diagnostic (Diag) field set to Control Detection Time Expired
	value;		value;
	o the value of the Your Discriminator field is set to the value the		o the value of the Your Discriminator field is set to the value the
	egress LSR has been using to demultiplex that BFD multipoint		egress LSR has been using to demultiplex that BFD multipoint
	session;		session;
	o BFD Control packet is encapsulated in IP/UDP with the destination		o BFD Control packet MAY be encapsulated in IP/UDP with the
	IP address of the ingress LSR and the UDP destination port number		destination IP address of the ingress LSR and the UDP destination
	set to 4784 per [RFC5883]		port number set to 4784 per [RFC5883]. If non-IP encapsulation is
			used, then a BFD Control packet is encapsulated using PW-ACH
			encapsulation (without IP/UDP Headers) (0x0007) [RFC5885];
	o these BFD Control packets are transmitted at the rate of one per		o these BFD Control packets are transmitted at the rate of one per
	second until either it receives a control packet valid for this		second until either it receives a control packet valid for this
	BFD session with the Final (F) bit set from the ingress LSR or the		BFD session with the Final (F) bit set from the ingress LSR or the
	defect condition clears; however to improve the likelihood of		defect condition clears; however to improve the likelihood of
	notifying the ingress LSR of the failure of the p2mp MPLS LSP, the		notifying the ingress LSR of the failure of the p2mp MPLS LSP, the
	egress LSR SHOULD initially transmit three BFD Control packets		egress LSR SHOULD initially transmit three BFD Control packets
	defined above in short succession.		defined above in short succession.
	An ingress LSR that has received the BFD Control packet, as described		An ingress LSR that has received the BFD Control packet, as described
	above, sends the unicast IP/UDP encapsulated BFD Control packet with		above, sends the unicast IP/UDP encapsulated BFD Control packet with
	the Final (F) bit set to the egress LSR.		the Final (F) bit set to the egress LSR.
	4.3. Control Plane		6. Security Considerations
	The BGP-BFD Attribute [I-D.ietf-bess-mvpn-fast-failover] MAY be used
	to bootstrap multipoint BFD session on a tail.
	5. Security Considerations
	This document does not introduce new security aspects but inherits		This document does not introduce new security aspects but inherits
	all security considerations from [RFC5880], [RFC5884], [RFC7726],		all security considerations from [RFC5880], [RFC5884], [RFC7726],
	[RFC8562], [RFC8029], and [RFC6425].		[RFC8562], [RFC8029], and [RFC6425].
	Also, BFD for p2mp MPLS LSP MUST follow the requirements listed in		Also, BFD for p2mp MPLS LSP MUST follow the requirements listed in
	section 4.1 [RFC4687] to avoid congestion in the control plane or the		section 4.1 [RFC4687] to avoid congestion in the control plane or the
	data plane caused by the rate of generating BFD Control packets. An		data plane caused by the rate of generating BFD Control packets. An
	operator SHOULD consider the amount of extra traffic generated by		operator SHOULD consider the amount of extra traffic generated by
	p2mp BFD when selecting the interval at which the MultipointHead will		p2mp BFD when selecting the interval at which the MultipointHead will
	transmit BFD Control packets. The operator MAY consider the size of		transmit BFD Control packets. The operator MAY consider the size of
	the packet the MultipointHead transmits periodically as using IP/UDP		the packet the MultipointHead transmits periodically as using IP/UDP
	encapsulation, which adds up to 28 octets, more than 50% of the BFD		encapsulation, which adds up to 28 octets, more than 50% of the BFD
	Control packet length, comparing to G-ACh encapsulation.		Control packet length, comparing to G-ACh encapsulation.
	6. IANA Considerations		7. IANA Considerations
	IANA is requested to allocate value (TBA1) from its MPLS Generalized		IANA is requested to allocate value (TBA1) from its MPLS Generalized
	Associated Channel (G-ACh) Types registry.		Associated Channel (G-ACh) Types registry.
	+-------+------------------------+---------------+		+-------+------------------------+---------------+
	| Value | Description | Reference |		| Value | Description | Reference |
	+-------+------------------------+---------------+		+-------+------------------------+---------------+
	| TBA1 | Multipoint BFD Session | This document |		| TBA1 | Multipoint BFD Session | This document |
	+-------+------------------------+---------------+		+-------+------------------------+---------------+
	Table 1: Multipoint BFD Session G-ACh Type		Table 1: Multipoint BFD Session G-ACh Type
	7. Acknowledgements		8. Acknowledgements
	The author sincerely appreciates the comments received from Andrew		The author sincerely appreciates the comments received from Andrew
	Malis and thought stimulating questions from Carlos Pignataro.		Malis and thought stimulating questions from Carlos Pignataro.
	8. References		9. References
	8.1. Normative References		9.1. Normative References
	[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>.
	[RFC5586] Bocci, M., Ed., Vigoureux, M., Ed., and S. Bryant, Ed.,		[RFC5586] Bocci, M., Ed., Vigoureux, M., Ed., and S. Bryant, Ed.,
	"MPLS Generic Associated Channel", RFC 5586,		"MPLS Generic Associated Channel", RFC 5586,
	DOI 10.17487/RFC5586, June 2009,		DOI 10.17487/RFC5586, June 2009,
	<https://www.rfc-editor.org/info/rfc5586>.		<https://www.rfc-editor.org/info/rfc5586>.
	skipping to change at page 8, line 45 ¶		skipping to change at page 8, line 45 ¶
	[RFC5883] Katz, D. and D. Ward, "Bidirectional Forwarding Detection		[RFC5883] Katz, D. and D. Ward, "Bidirectional Forwarding Detection
	(BFD) for Multihop Paths", RFC 5883, DOI 10.17487/RFC5883,		(BFD) for Multihop Paths", RFC 5883, DOI 10.17487/RFC5883,
	June 2010, <https://www.rfc-editor.org/info/rfc5883>.		June 2010, <https://www.rfc-editor.org/info/rfc5883>.
	[RFC5884] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow,		[RFC5884] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow,
	"Bidirectional Forwarding Detection (BFD) for MPLS Label		"Bidirectional Forwarding Detection (BFD) for MPLS Label
	Switched Paths (LSPs)", RFC 5884, DOI 10.17487/RFC5884,		Switched Paths (LSPs)", RFC 5884, DOI 10.17487/RFC5884,
	June 2010, <https://www.rfc-editor.org/info/rfc5884>.		June 2010, <https://www.rfc-editor.org/info/rfc5884>.
			[RFC5885] Nadeau, T., Ed. and C. Pignataro, Ed., "Bidirectional
			Forwarding Detection (BFD) for the Pseudowire Virtual
			Circuit Connectivity Verification (VCCV)", RFC 5885,
			DOI 10.17487/RFC5885, June 2010,
			<https://www.rfc-editor.org/info/rfc5885>.
	[RFC6425] Saxena, S., Ed., Swallow, G., Ali, Z., Farrel, A.,		[RFC6425] Saxena, S., Ed., Swallow, G., Ali, Z., Farrel, A.,
	Yasukawa, S., and T. Nadeau, "Detecting Data-Plane		Yasukawa, S., and T. Nadeau, "Detecting Data-Plane
	Failures in Point-to-Multipoint MPLS - Extensions to LSP		Failures in Point-to-Multipoint MPLS - Extensions to LSP
	Ping", RFC 6425, DOI 10.17487/RFC6425, November 2011,		Ping", RFC 6425, DOI 10.17487/RFC6425, November 2011,
	<https://www.rfc-editor.org/info/rfc6425>.		<https://www.rfc-editor.org/info/rfc6425>.
	[RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and		[RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and
	L. Yong, "The Use of Entropy Labels in MPLS Forwarding",		L. Yong, "The Use of Entropy Labels in MPLS Forwarding",
	RFC 6790, DOI 10.17487/RFC6790, November 2012,		RFC 6790, DOI 10.17487/RFC6790, November 2012,
	<https://www.rfc-editor.org/info/rfc6790>.		<https://www.rfc-editor.org/info/rfc6790>.
	skipping to change at page 9, line 41 ¶		skipping to change at page 9, line 47 ¶
	[RFC8562] Katz, D., Ward, D., Pallagatti, S., Ed., and G. Mirsky,		[RFC8562] Katz, D., Ward, D., Pallagatti, S., Ed., and G. Mirsky,
	Ed., "Bidirectional Forwarding Detection (BFD) for		Ed., "Bidirectional Forwarding Detection (BFD) for
	Multipoint Networks", RFC 8562, DOI 10.17487/RFC8562,		Multipoint Networks", RFC 8562, DOI 10.17487/RFC8562,
	April 2019, <https://www.rfc-editor.org/info/rfc8562>.		April 2019, <https://www.rfc-editor.org/info/rfc8562>.
	[RFC8563] Katz, D., Ward, D., Pallagatti, S., Ed., and G. Mirsky,		[RFC8563] Katz, D., Ward, D., Pallagatti, S., Ed., and G. Mirsky,
	Ed., "Bidirectional Forwarding Detection (BFD) Multipoint		Ed., "Bidirectional Forwarding Detection (BFD) Multipoint
	Active Tails", RFC 8563, DOI 10.17487/RFC8563, April 2019,		Active Tails", RFC 8563, DOI 10.17487/RFC8563, April 2019,
	<https://www.rfc-editor.org/info/rfc8563>.		<https://www.rfc-editor.org/info/rfc8563>.
	8.2. Informative References		9.2. Informative References
	[I-D.ietf-bess-mvpn-fast-failover]
	Morin, T., Kebler, R., and G. Mirsky, "Multicast VPN Fast
	Upstream Failover", draft-ietf-bess-mvpn-fast-failover-15
	(work in progress), January 2021.
	[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing		[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
	Architecture", RFC 4291, DOI 10.17487/RFC4291, February		Architecture", RFC 4291, DOI 10.17487/RFC4291, February
	2006, <https://www.rfc-editor.org/info/rfc4291>.		2006, <https://www.rfc-editor.org/info/rfc4291>.
	[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>.
			[RFC9026] Morin, T., Ed., Kebler, R., Ed., and G. Mirsky, Ed.,
			"Multicast VPN Fast Upstream Failover", RFC 9026,
			DOI 10.17487/RFC9026, April 2021,
			<https://www.rfc-editor.org/info/rfc9026>.
	Authors' Addresses		Authors' Addresses
	Greg Mirsky		Greg Mirsky
	ZTE Corp.		Ericsson
	Email: gregimirsky@gmail.com		Email: gregimirsky@gmail.com
	Gyan Mishra		Gyan Mishra
	Verizon Inc.		Verizon Inc.
	Email: gyan.s.mishra@verizon.com		Email: gyan.s.mishra@verizon.com
	Donald Eastlake, 3rd		Donald Eastlake, 3rd
	Futurewei Technologies		Futurewei Technologies
End of changes. 23 change blocks.
	53 lines changed or deleted		76 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/