< draft-zzhang-mpls-rmr-multicast-02.txt		draft-zzhang-mpls-rmr-multicast-03.txt >
	MPLS Z. Zhang		MPLS Z. Zhang
	Internet-Draft Juniper Networks		Internet-Draft Juniper Networks
	Intended status: Informational S. Esale		Intended status: Informational S. Esale
	Expires: July 29, 2019 Juniper Networks, Inc.		Expires: November 8, 2019 Juniper Networks, Inc.
	January 25, 2019		May 7, 2019
	Resilient MPLS Rings and Multicast		Resilient MPLS Rings and Multicast
	draft-zzhang-mpls-rmr-multicast-02		draft-zzhang-mpls-rmr-multicast-03
	Abstract		Abstract
	With Resilient MPLS Rings (RMR), although all existing multicast		With Resilient MPLS Rings (RMR), although all existing multicast
	procedures and solutions can work as is, there are optimizations that		procedures and solutions can work as is, there are optimizations that
	could be done for RSVP-TE P2MP tunnel signaling and Fast-ReRouting		could be done for RSVP-TE P2MP tunnel signaling and Fast-ReRouting
	for both mLDP and RSVP-TE P2MP tunnels. This document describes RMR		for both mLDP and RSVP-TE P2MP tunnels. This document describes RMR
	multicast on a high level, with detailed protocol procedure for RSVP-		multicast on a high level, with detailed protocol procedure for RSVP-
	TE P2MP optimizations specified in a separate document. This		TE P2MP optimizations specified in a separate document. This
	document also discusses end to end multicast when there are RMRs.		document also discusses end to end multicast when there are RMRs.
	skipping to change at page 1, line 37 ¶		skipping to change at page 1, line 37 ¶
	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 July 29, 2019.		This Internet-Draft will expire on November 8, 2019.
	Copyright Notice		Copyright Notice
	Copyright (c) 2019 IETF Trust and the persons identified as the		Copyright (c) 2019 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 14 ¶		skipping to change at page 2, line 14 ¶
	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. P2MP/MP2MP Tunnels on a Ring . . . . . . . . . . . . . . . . 3		2. P2MP/MP2MP Tunnels on a Ring . . . . . . . . . . . . . . . . 3
	2.1. Tunnel Protection and FRR . . . . . . . . . . . . . . . . 3		2.1. Tunnel Protection and FRR . . . . . . . . . . . . . . . . 3
	3. End to End Tunnels with Rings . . . . . . . . . . . . . . . . 4		3. End to End Tunnels with Rings . . . . . . . . . . . . . . . . 4
	4. End to End Native Multicast with Rings . . . . . . . . . . . 5		4. End to End Native Multicast with Rings . . . . . . . . . . . 4
	4.1. Native Multicast in the Global Routing Table . . . . . . 5		4.1. Native Multicast in the Global Routing Table . . . . . . 4
	4.2. mLDP Inband Signaling . . . . . . . . . . . . . . . . . . 5		4.2. mLDP Inband Signaling . . . . . . . . . . . . . . . . . . 4
	4.3. Overlay Multicast Services . . . . . . . . . . . . . . . 5		4.3. Overlay Multicast Services . . . . . . . . . . . . . . . 4
	4.3.1. Tunnel Segmentation . . . . . . . . . . . . . . . . . 5		4.3.1. Tunnel Segmentation . . . . . . . . . . . . . . . . . 5
	5. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 6		5. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 6		6. Security Considerations . . . . . . . . . . . . . . . . . . . 5
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
	8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6		8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . 6		9. References . . . . . . . . . . . . . . . . . . . . . . . . . 6
	9.1. Normative References . . . . . . . . . . . . . . . . . . 6		9.1. Normative References . . . . . . . . . . . . . . . . . . 6
	9.2. Informative References . . . . . . . . . . . . . . . . . 7		9.2. Informative References . . . . . . . . . . . . . . . . . 6
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7
	1. Introduction		1. Introduction
	This document discusses how multicast works with Resilient MPLS Rings		This document discusses how multicast works with Resilient MPLS Rings
	[I-D.ietf-mpls-rmr]. It is expected that readers are familiar with		[I-D.ietf-mpls-rmr]. It is expected that readers are familiar with
	the concept and terms in [I-D.ietf-mpls-rmr].		the concept and terms in [I-D.ietf-mpls-rmr].
	All existing multicast procedures and solutions can work as is. This		All existing multicast procedures and solutions can work as is. This
	include both mpls multicast tunnels and end-to-end multicast that		include both mpls multicast tunnels and end-to-end multicast that
	makes use of multicast tunnels. Ring topology is just a special case		makes use of multicast tunnels. Ring topology is just a special case
	of general topologies so all existing RSVP-TE P2MP [RFC4875] and mLDP		of general topologies so all existing RSVP-TE P2MP [RFC4875] and mLDP
	[RFC6388] tunnels can be set up using existing protocols and		[RFC6388] tunnels can be set up using existing protocols and
	procedures. An Ingress Replication (IR) tunnel [RFC7988] consists a		procedures. An Ingress Replication (IR) tunnel [RFC7988] consists a
	bunch of P2P LSPs, and it does not matter whether a component LSP is		bunch of P2P LSPs, and it does not matter whether a component LSP is
	a plain old LSP or a Ring LSP.		a plain old LSP or a Ring LSP.
	On the other hand, there are optimizations that could be done for		On the other hand, there are optimizations that could be done for
	RSVP-TE P2MP tunnel signaling and Fast-ReRouting (FRR) for both mLDP		RSVP-TE P2MP tunnel signaling and Fast-ReRouting (FRR) for both mLDP
	and RSVP-TE P2MP tunnels. This document describes that on a high		and RSVP-TE P2MP tunnels. This document describes that on a high
	level, with detailed protocol procedure for RSVP-TE P2MP		level, and discusses end to end multicast when there are RMRs even
	optimizations specified in [I-D.zzhang-teas-rmr-rsvp-p2mp]. This
	document also discusses end to end multicast when there are RMRs even
	though RMR could be transparent to multicast.		though RMR could be transparent to multicast.
	2. P2MP/MP2MP Tunnels on a Ring		2. P2MP/MP2MP Tunnels on a Ring
	Because mLDP label mapping messages are merged as they propagate from		Because mLDP label mapping messages are merged as they propagate from
	the leaves towards the root, ring topology does not lead to any		the leaves towards the root, ring topology does not lead to any
	further optimization.		further optimization in tunnel signaling.
	For a conventionally signaled RSVP-TE P2MP tunnel, an ingress LSR
	discovers leaves and signals one sub-LSP for each leaf. Even though
	the forwarding state is merged at each hop (i.e, one incoming label
	mapping to multiple outgoing entries), the control plane maintains
	individual sub-LSP state. This leads to lots of redundant state on
	routers close to the ingress. With RMR, this can be optimized such
	that only a single LSP is signaled, with all the leaves listed in the
	PATH message. As the PATH message passes along the ring, the leaves
	send RESV messages, but only one RESV message reaches the tunnel
	ingress.
	The ingress LSR may also send PATH messages in both directions, so
	that the tunnel is set up in such a way that minimum delay is
	incurred for traffic to reach all leaves. Alternatively, the ingress
	may send PATH message only in one direction for best bandwidth
	utilization. For example, a leaf D is three hops away from the
	ingress A in clockwise direction (A,B,C,D) and four hops away in the
	other direction (A,E,F,G,D), but G is also a leaf so it may be better
	to just send the PATH message in the anticlockwise direction.
	Each router establishes forwarding state accordingly. Transit
	routers switches traffic towards downstream. A transit router could
	also be a leaf router and in that case it does "drop and continue" -
	sends traffic off the ring and switches traffic downstream.
	MP2MP RSVP-TE tunnel can also be easily achieved. The PATH message
	could carry a label for the downstream router to send traffic to its
	upstream. Then the ingress and each leaf can use the same tunnel to
	send traffic to each other.
	The PATH message does not need to list all leaves. As long as a leaf		However RSVP-TE P2MP tunnel signaling and procedures can be greatly
	somehow determines that it is a leaf, it can send RESV message when		optimized, as specified in [I-D.zzhang-teas-rmr-rsvp-p2mp].
	it receives the PATH message. This makes it leaf-initiated like mLDP
	P2MP tunnels, which may have advantages in certain situations.
	2.1. Tunnel Protection and FRR		2.1. Tunnel Protection and FRR
	Each node on a ring signals two counter-rotating MP2P RSVP-TE LSPs to		Each node on a ring signals two counter-rotating MP2P Ring LSPs to
	itself. As these LSPs are self-signaled after the discovery of the		itself. As these LSPs are self-signaled after the discovery of the
	ring, they can be used to protect P2MP LSPs on ring. So neither mLDP		ring, they can be used to protect P2MP LSPs on ring. So neither mLDP
	nor RSVP-TE has to setup a separate P2P bypass LSPs for link and node		nor RSVP-TE has to setup a separate P2P bypass LSPs for link and node
	protection. For instance, consider a ring with 8 nodes.		protection. For instance, consider a ring with 8 nodes:
	Root		Root
	R0 . . . R1		R0 . . . R1
	. .		. .
	R7 R2 Leaf		R7 R2 Leaf
	| . . |		| . . |
	Anti- | . RingID=17 . |		Anti- | . RingID=17 . |
	Clockwise v . . v Clockwise		Clockwise v . . v Clockwise
	Leaf R6 R3		Leaf R6 R3
	skipping to change at page 7, line 9 ¶		skipping to change at page 6, line 27 ¶
	[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>.
	9.2. Informative References		9.2. Informative References
	[I-D.zzhang-teas-rmr-rsvp-p2mp]		[I-D.zzhang-teas-rmr-rsvp-p2mp]
	Zhang, Z., Deshmukh, A., and R. Singh, "RSVP-TE P2MP		Zhang, Z., Deshmukh, A., and R. Singh, "RSVP-TE P2MP
	Tunnels on RMR", draft-zzhang-teas-rmr-rsvp-p2mp-00 (work		Tunnels on RMR", draft-zzhang-teas-rmr-rsvp-p2mp-02 (work
	in progress), July 2018.		in progress), January 2019.
	[RFC4761] Kompella, K., Ed. and Y. Rekhter, Ed., "Virtual Private		[RFC4761] Kompella, K., Ed. and Y. Rekhter, Ed., "Virtual Private
	LAN Service (VPLS) Using BGP for Auto-Discovery and		LAN Service (VPLS) Using BGP for Auto-Discovery and
	Signaling", RFC 4761, DOI 10.17487/RFC4761, January 2007,		Signaling", RFC 4761, DOI 10.17487/RFC4761, January 2007,
	<https://www.rfc-editor.org/info/rfc4761>.		<https://www.rfc-editor.org/info/rfc4761>.
	[RFC4762] Lasserre, M., Ed. and V. Kompella, Ed., "Virtual Private		[RFC4762] Lasserre, M., Ed. and V. Kompella, Ed., "Virtual Private
	LAN Service (VPLS) Using Label Distribution Protocol (LDP)		LAN Service (VPLS) Using Label Distribution Protocol (LDP)
	Signaling", RFC 4762, DOI 10.17487/RFC4762, January 2007,		Signaling", RFC 4762, DOI 10.17487/RFC4762, January 2007,
	<https://www.rfc-editor.org/info/rfc4762>.		<https://www.rfc-editor.org/info/rfc4762>.
End of changes. 12 change blocks.
	55 lines changed or deleted		21 lines changed or added
This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/