< draft-szcl-mboned-redundant-ingress-failover-00.txt		draft-szcl-mboned-redundant-ingress-failover-01.txt >
	MBONED WG G. Shepherd		MBONED WG G. Shepherd
	Internet-Draft Cisco Systems, Inc.		Internet-Draft Cisco Systems, Inc.
	Intended status: Informational Z. Zhang, Ed.		Intended status: Informational Z. Zhang, Ed.
	Expires: April 28, 2021 ZTE Corporation		Expires: January 9, 2022 ZTE Corporation
	Y. Liu		Y. Liu
	China Mobile		China Mobile
	Y. Cheng		Y. Cheng
	China Unicom		China Unicom
	October 25, 2020		July 8, 2021
	Multicast Redundant Ingress Router Failover		Multicast Redundant Ingress Router Failover
	draft-szcl-mboned-redundant-ingress-failover-00		draft-szcl-mboned-redundant-ingress-failover-01
	Abstract		Abstract
	This document discusses the redundant ingress router failover in		This document discusses the redundant ingress router failover in
	multicast domain.		multicast domain.
	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.
	skipping to change at page 1, line 36 ¶		skipping to change at page 1, line 36 ¶
	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 April 28, 2021.		This Internet-Draft will expire on January 9, 2022.
	Copyright Notice		Copyright Notice
	Copyright (c) 2020 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
	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
	skipping to change at page 2, line 16 ¶		skipping to change at page 2, line 16 ¶
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
	3. Multicast Redundant Ingress Router Failover . . . . . . . . . 3		3. Multicast Redundant Ingress Router Failover . . . . . . . . . 3
	3.1. Swichover . . . . . . . . . . . . . . . . . . . . . . . . 4		3.1. Swichover . . . . . . . . . . . . . . . . . . . . . . . . 4
	4. Stand-by Modes . . . . . . . . . . . . . . . . . . . . . . . 6		4. Stand-by Modes . . . . . . . . . . . . . . . . . . . . . . . 6
	4.1. Cold . . . . . . . . . . . . . . . . . . . . . . . . . . 6		4.1. Cold . . . . . . . . . . . . . . . . . . . . . . . . . . 6
	4.2. Warm . . . . . . . . . . . . . . . . . . . . . . . . . . 7		4.2. Warm . . . . . . . . . . . . . . . . . . . . . . . . . . 7
	4.3. Hot . . . . . . . . . . . . . . . . . . . . . . . . . . . 7		4.3. Hot . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
	4.4. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 8		4.4. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 8
	5. Security Considerations . . . . . . . . . . . . . . . . . . . 10		5. Security Considerations . . . . . . . . . . . . . . . . . . . 10
	6. References . . . . . . . . . . . . . . . . . . . . . . . . . 10		6. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
	6.1. Normative References . . . . . . . . . . . . . . . . . . 10		6.1. Normative References . . . . . . . . . . . . . . . . . . 10
	6.2. Informative References . . . . . . . . . . . . . . . . . 10		6.2. Informative References . . . . . . . . . . . . . . . . . 10
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
	1. Introduction		1. Introduction
	The multicast redundant ingress router failover is an important issue		The multicast redundant ingress router failover is an important issue
	in multicast deployment. This document tries to do a research on it		in multicast deployment. This document tries to do a research on it
	in the multicast domain. The Multicast Domain is a domain which is		in the multicast domain. The Multicast Domain is a domain which is
	used to forward multicast flow according to specific multicast		used to forward multicast flow according to specific multicast
	technologies, such as PIM ([RFC7761]), BIER ([RFC8279]), P2MP TE		technologies, such as PIM ([RFC7761]), BIER ([RFC8279]), P2MP TE
	tunnel ([RFC4875]), MLDP ([RFC6388]), etc. This domain may or may		tunnel ([RFC4875]), MLDP ([RFC6388]), etc. The domain may or may not
	not connect the multicast source and receiver directly.		connect the multicast source and receiver directly.
	The ingress router is close to the multicast source. The ingress		The ingress router is close to the multicast source. The ingress
	router may connect the multicast source directly, or there may be		router may connect the multicast source directly, or there may be
	multiple hops between the ingress router and the multicast source.		multiple hops between the ingress router and the multicast source.
	In the multicast domain, the ingress router is the most adjacent		In the multicast domain, the ingress router is the most adjacent
	router to the multicast source. It's also called the first-hop		router to the multicast source. It's also called the first-hop
	router in PIM, or BFIR in BIER, or Ingress LSR in P2MP TE tunnel or		router in PIM, or BFIR in BIER, or Ingress LSR in P2MP TE tunnel or
	MLDP.		MLDP.
	The failover function between the multicast source and the ingress		The failover function between the multicast source and the ingress
	skipping to change at page 6, line 27 ¶		skipping to change at page 6, line 27 ¶
	domain, the controller should let the IR2 to forward multicast		domain, the controller should let the IR2 to forward multicast
	flow to the ERs.		flow to the ERs.
	4. Stand-by Modes		4. Stand-by Modes
	In case there are more than one IRs can be the UMH, and there is no		In case there are more than one IRs can be the UMH, and there is no
	other path from an IR to ERs in case of the IR fails, the IR needs to		other path from an IR to ERs in case of the IR fails, the IR needs to
	be switched.		be switched.
	Usually there are three types of stand-by modes in multicast IR		Usually there are three types of stand-by modes in multicast IR
	protection. [I-D.ietf-bess-mvpn-fast-failover] has some description		protection. [RFC9026] has some description on it. This document
	on it. This document discusses the detail of the three modes here.		discusses the detail of the three modes here.
	The ER may send request to upstream router or IR when it finds the		The ER may send request to upstream router or IR when it finds the
	node or path failure. The request from the ER may be the PIM tree		node or path failure. The request from the ER may be the PIM tree
	building, or BIER overlay protocol signaling, or LSP building, or		building, or BIER overlay protocol signaling, or LSP building, or
	some other ways to let IR knows whether forwards the multicast flow.		some other ways to let IR knows whether forwards the multicast flow.
	4.1. Cold		4.1. Cold
	In cold standby mode, the ER selects an SIR, for example IR1 in		In cold standby mode, the ER selects an SIR, for example IR1 in
	figure 1, as the SIR and signals to it to get the multicast flow.		figure 1, as the SIR and signals to it to get the multicast flow.
	skipping to change at page 7, line 38 ¶		skipping to change at page 7, line 38 ¶
	o For ER, the ER does not select the SIR or BIR. The ER just signal		o For ER, the ER does not select the SIR or BIR. The ER just signal
	to both of them.		to both of them.
	o For the intermediate routers, they know nothing about the role of		o For the intermediate routers, they know nothing about the role of
	IR, they just do the packet forwarding. There is no duplicate		IR, they just do the packet forwarding. There is no duplicate
	packets in the domain.		packets in the domain.
	In case of the IR switchover, the BIR detects the failure of the SIR		In case of the IR switchover, the BIR detects the failure of the SIR
	and switch to SIR. There is packet loss during the IR switchover.		and switch to SIR. There is packet loss during the IR switchover.
			In some deployments, the SIR and BIR may in charge of different
			multicast flow. For a specific multicast flow, the SIR may be IR1,
			for another multicast flow, the SIR may be IR2. So the two IRs can
			share the multicast forwarding load. And another possible deployment
			is, the two IRs can in charge of different ERs for one multicast
			flow. For example, IR1 sends the multicast flow to some of the ERs,
			and IR2 send the multicast flow to the other ERs. In case IR1
			detects there is something wrong between IR1 and the ERs, IR1 may
			notify IR2 to take over the responsibility of forwarding the
			multicast flow to these ERs that receive flow from IR1 before.
	4.3. Hot		4.3. Hot
	In Hot standby mode, the ER signals to both IRs.		In Hot standby mode, the ER signals to both IRs.
	Both IRs are sending the flow to the ER. The ER must discard the		Both IRs are sending the flow to the ER. The ER must discard the
	duplicate flow from one of the IRs.		duplicate flow from one of the IRs.
	In this situation, there are no SIR or BIR. Only ER knows which IR		In this situation, there are no SIR or BIR. Only ER knows which IR
	is the SIR.		is the SIR.
	skipping to change at page 10, line 44 ¶		skipping to change at page 10, line 44 ¶
	2016, <https://www.rfc-editor.org/info/rfc7761>.		2016, <https://www.rfc-editor.org/info/rfc7761>.
	[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>.
	6.2. Informative References		6.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-11
	(work in progress), October 2020.
	[I-D.ietf-pim-sr-p2mp-policy]		[I-D.ietf-pim-sr-p2mp-policy]
	Voyer, D., Filsfils, C., Parekh, R., Bidgoli, H., and Z.		Voyer, D., Filsfils, C., Parekh, R., Bidgoli, H., and Z.
	Zhang, "Segment Routing Point-to-Multipoint Policy",		Zhang, "Segment Routing Point-to-Multipoint Policy",
	draft-ietf-pim-sr-p2mp-policy-00 (work in progress), July		draft-ietf-pim-sr-p2mp-policy-02 (work in progress),
	2020.		February 2021.
			[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 Shepherd		Greg Shepherd
	Cisco Systems, Inc.		Cisco Systems, Inc.
	170 W. Tasman Dr.		170 W. Tasman Dr.
	San Jose		San Jose
	US		US
	Email: gjshep@gmail.com		Email: gjshep@gmail.com
	Zheng Zhang (editor)		Zheng Zhang (editor)
	ZTE Corporation		ZTE Corporation
	Nanjing		Nanjing
	China		China
	Email: zhang.zheng@zte.com.cn		Email: zhang.zheng@zte.com.cn
	Yisong Liu		Yisong Liu
	China Mobile		China Mobile
			Beijing
	Email: liuyisong@chinamobile.com		Email: liuyisong@chinamobile.com
	Ying Cheng		Ying Cheng
	China Unicom		China Unicom
	Beijing		Beijing
	China		China
	Email: chengying10@chinaunicom.cn		Email: chengying10@chinaunicom.cn
End of changes. 12 change blocks.
	17 lines changed or deleted		29 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/