< draft-pfister-bier-mld-02.txt		draft-pfister-bier-mld-03.txt >
	Network Working Group P. Pfister		Network Working Group P. Pfister
	Internet-Draft IJ. Wijnands		Internet-Draft IJ. Wijnands
	Intended status: Standards Track S. Venaas		Intended status: Standards Track S. Venaas
	Expires: May 4, 2017 Cisco Systems		Expires: September 10, 2017 Cisco Systems
			C. Wang
			Z. Zhang
			ZTE Corporation
	M. Stenberg		M. Stenberg
	October 31, 2016		March 9, 2017
	BIER Ingress Multicast Flow Overlay using Multicast Listener Discovery		BIER Ingress Multicast Flow Overlay using Multicast Listener Discovery
	Protocols		Protocols
	draft-pfister-bier-mld-02		draft-pfister-bier-mld-03
	Abstract		Abstract
	This document specifies the ingress part of a multicast flow overlay		This document specifies the ingress part of a multicast flow overlay
	for BIER networks. Using existing multicast listener discovery		for BIER networks. Using existing multicast listener discovery
	protocols, it enables multicast membership information sharing from		protocols, it enables multicast membership information sharing from
	egress routers, acting as listeners, toward ingress routers, acting		egress routers, acting as listeners, toward ingress routers, acting
	as queriers. Ingress routers keep per-egress-router state, used to		as queriers. Ingress routers keep per-egress-router state, used to
	construct the BIER bit mask associated with IP multicast packets		construct the BIER bit mask associated with IP multicast packets
	entering the BIER domain.		entering the BIER domain.
	skipping to change at page 1, line 39 ¶		skipping to change at page 1, line 42 ¶
	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 http://datatracker.ietf.org/drafts/current/.		Drafts is at http://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 May 4, 2017.		This Internet-Draft will expire on September 10, 2017.
	Copyright Notice		Copyright Notice
	Copyright (c) 2016 IETF Trust and the persons identified as the		Copyright (c) 2017 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
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://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
	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. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
	3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3		3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3
	4. Applicability Statement . . . . . . . . . . . . . . . . . . . 4		4. Applicability Statement . . . . . . . . . . . . . . . . . . . 4
	5. Querier and Listener Specifications . . . . . . . . . . . . . 4		5. Querier and Listener Specifications . . . . . . . . . . . . . 4
	5.1. Configuration Parameters . . . . . . . . . . . . . . . . 4		5.1. Configuration Parameters . . . . . . . . . . . . . . . . 5
	5.2. MLDv2 instances. . . . . . . . . . . . . . . . . . . . . 5		5.2. MLDv2 instances. . . . . . . . . . . . . . . . . . . . . 5
	5.2.1. Sending Queries . . . . . . . . . . . . . . . . . . . 5		5.2.1. Sending Queries . . . . . . . . . . . . . . . . . . . 6
	5.2.2. Sending Reports . . . . . . . . . . . . . . . . . . . 6		5.2.2. Sending Reports . . . . . . . . . . . . . . . . . . . 6
	5.2.3. Receiving Queries . . . . . . . . . . . . . . . . . . 6		5.2.3. Receiving Queries . . . . . . . . . . . . . . . . . . 6
	5.2.4. Receiving Reports . . . . . . . . . . . . . . . . . . 7		5.2.4. Receiving Reports . . . . . . . . . . . . . . . . . . 7
	5.3. Packet Forwarding . . . . . . . . . . . . . . . . . . . . 7		5.3. Packet Forwarding . . . . . . . . . . . . . . . . . . . . 7
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 7		6. Security Considerations . . . . . . . . . . . . . . . . . . . 7
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8		8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8
	8.1. Normative References . . . . . . . . . . . . . . . . . . 8		9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
	8.2. Informative References . . . . . . . . . . . . . . . . . 8		9.1. Normative References . . . . . . . . . . . . . . . . . . 8
	Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 9		9.2. Informative References . . . . . . . . . . . . . . . . . 9
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9		Appendix A. BIER Use Case in Data Centers . . . . . . . . . . . 9
			A.1. Convention and Terminology . . . . . . . . . . . . . . . 11
			A.2. BIER in data centers . . . . . . . . . . . . . . . . . . 11
			A.3. A BIER MLD solution for Virtual Network information . . . 12
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
	1. Introduction		1. Introduction
	The Bit Index Explicit Replication (BIER -		The Bit Index Explicit Replication (BIER -
	[I-D.ietf-bier-architecture]) forwarding technique enables IP		[I-D.ietf-bier-architecture]) forwarding technique enables IP
	multicast transport across a BIER domain. When receiving or		multicast transport across a BIER domain. When receiving or
	originating a packet, ingress routers have to construct a bit mask		originating a packet, ingress routers have to construct a bit mask
	indicating which BIER egress routers located within the same BIER		indicating which BIER egress routers located within the same BIER
	domain will receive the packet. A stateless approach would consist		domain will receive the packet. A stateless approach would consist
	in forwarding all incoming packets toward all egress routers, which		in forwarding all incoming packets toward all egress routers, which
	skipping to change at page 8, line 9 ¶		skipping to change at page 8, line 20 ¶
	o Redirect undesired traffic toward the spoofed router by		o Redirect undesired traffic toward the spoofed router by
	subscribing to undesired multicast traffic.		subscribing to undesired multicast traffic.
	o Prevent desired multicast traffic from reaching the spoofed router		o Prevent desired multicast traffic from reaching the spoofed router
	by unsubscribing to some desired multicast traffic.		by unsubscribing to some desired multicast traffic.
	7. IANA Considerations		7. IANA Considerations
	This specification does not require any action from IANA.		This specification does not require any action from IANA.
	8. References		8. Acknowledgements
	8.1. Normative References		Comments concerning this document are very welcome.
			9. References
			9.1. Normative References
	[RFC2113] Katz, D., "IP Router Alert Option", RFC 2113,		[RFC2113] Katz, D., "IP Router Alert Option", RFC 2113,
	DOI 10.17487/RFC2113, February 1997,		DOI 10.17487/RFC2113, February 1997,
	<http://www.rfc-editor.org/info/rfc2113>.		<http://www.rfc-editor.org/info/rfc2113>.
	[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,
	<http://www.rfc-editor.org/info/rfc2119>.		<http://www.rfc-editor.org/info/rfc2119>.
	skipping to change at page 8, line 38 ¶		skipping to change at page 9, line 5 ¶
	Discovery Version 2 (MLDv2) for IPv6", RFC 3810,		Discovery Version 2 (MLDv2) for IPv6", RFC 3810,
	DOI 10.17487/RFC3810, June 2004,		DOI 10.17487/RFC3810, June 2004,
	<http://www.rfc-editor.org/info/rfc3810>.		<http://www.rfc-editor.org/info/rfc3810>.
	[I-D.ietf-bier-architecture]		[I-D.ietf-bier-architecture]
	Wijnands, I., Rosen, E., Dolganow, A., Przygienda, T., and		Wijnands, I., Rosen, E., Dolganow, A., Przygienda, T., and
	S. Aldrin, "Multicast using Bit Index Explicit		S. Aldrin, "Multicast using Bit Index Explicit
	Replication", draft-ietf-bier-architecture-05 (work in		Replication", draft-ietf-bier-architecture-05 (work in
	progress), October 2016.		progress), October 2016.
	8.2. Informative References		9.2. Informative References
	[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6		[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
	(IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460,		(IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460,
	December 1998, <http://www.rfc-editor.org/info/rfc2460>.		December 1998, <http://www.rfc-editor.org/info/rfc2460>.
	[RFC2711] Partridge, C. and A. Jackson, "IPv6 Router Alert Option",		[RFC2711] Partridge, C. and A. Jackson, "IPv6 Router Alert Option",
	RFC 2711, DOI 10.17487/RFC2711, October 1999,		RFC 2711, DOI 10.17487/RFC2711, October 1999,
	<http://www.rfc-editor.org/info/rfc2711>.		<http://www.rfc-editor.org/info/rfc2711>.
	[RFC3306] Haberman, B. and D. Thaler, "Unicast-Prefix-based IPv6		[RFC3306] Haberman, B. and D. Thaler, "Unicast-Prefix-based IPv6
	Multicast Addresses", RFC 3306, DOI 10.17487/RFC3306,		Multicast Addresses", RFC 3306, DOI 10.17487/RFC3306,
	August 2002, <http://www.rfc-editor.org/info/rfc3306>.		August 2002, <http://www.rfc-editor.org/info/rfc3306>.
	[RFC4301] Kent, S. and K. Seo, "Security Architecture for the		[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
	Internet Protocol", RFC 4301, DOI 10.17487/RFC4301,		Internet Protocol", RFC 4301, DOI 10.17487/RFC4301,
	December 2005, <http://www.rfc-editor.org/info/rfc4301>.		December 2005, <http://www.rfc-editor.org/info/rfc4301>.
			[RFC5015] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano,
			"Bidirectional Protocol Independent Multicast (BIDIR-
			PIM)", RFC 5015, DOI 10.17487/RFC5015, October 2007,
			<http://www.rfc-editor.org/info/rfc5015>.
			[RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger,
			L., Sridhar, T., Bursell, M., and C. Wright, "Virtual
			eXtensible Local Area Network (VXLAN): A Framework for
			Overlaying Virtualized Layer 2 Networks over Layer 3
			Networks", RFC 7348, DOI 10.17487/RFC7348, August 2014,
			<http://www.rfc-editor.org/info/rfc7348>.
			[RFC7365] Lasserre, M., Balus, F., Morin, T., Bitar, N., and Y.
			Rekhter, "Framework for Data Center (DC) Network
			Virtualization", RFC 7365, DOI 10.17487/RFC7365, October
			2014, <http://www.rfc-editor.org/info/rfc7365>.
	[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, <http://www.rfc-editor.org/info/rfc7761>.		2016, <http://www.rfc-editor.org/info/rfc7761>.
	Appendix A. Acknowledgements		Appendix A. BIER Use Case in Data Centers
	Comments concerning this document are very welcome.		In current data center virtualization, virtual eXtensible Local Area
			Network (VXLAN) [RFC7348] is a kind of network virtualization overlay
			technology which is overlaid between NVEs and is intended for multi-
			tenancy data center networks, whose reference architecture is
			illustrated as per Figure 1.
			+--------+ +--------+
			| Tenant +--+ +----| Tenant |
			| System | | (') | System |
			+--------+ | ................ ( ) +--------+
			| +-+--+ . . +--+-+ (_)
			| | NVE|--. .--| NVE| |
			+--| | . . | |---+
			+-+--+ . . +--+-+
			/ . .
			/ . L3 Overlay . +--+-++--------+
			+--------+ / . Network . | NVE|| Tenant |
			| Tenant +--+ . .--| || System |
			| System | . . +--+-++--------+
			+--------+ ................
			Figure 1: NVO3 Architecture
			And there are two kinds of most common methods about how to forward
			BUM packets in this virtualization overlay network. One is using PIM
			as underlay multicast routing protocol to build explicit multicast
			distribution tree, such as PIM-SM [RFC7761] or PIM-BIDIR [RFC5015]
			multicast routing protocol. Then, when BUM packets arrive at NVE, it
			requires NVE to have a mapping between the VXLAN Network Identifier
			and the IP multicast group. According to the mapping, NVE can
			encapsulate BUM packets in a multicast packet which group address is
			the mapping IP multicast group address and steer them through
			explicit multicast distribution tree to the destination NVEs. This
			method has two serious drawbacks. It need the underlay network
			supports complicated multicast routing protocol and maintains
			multicast related per-flow state in every transit nodes. What is
			more, how to configure the ratio of the mapping between VNI and IP
			multicast group is also an issue. If the ratio is 1:1, there should
			be 16M multicast groups in the underlay network at maximum to map to
			the 16M VNIs, which is really a significant challenge for the data
			center devices. If the ratio is n:1, it would result in inefficiency
			bandwidth utilization which is not optimal in data center networks.
			The other method is using ingress replication to require each NVE to
			create a mapping between the VXLAN Network Identifier and the remote
			addresses of NVEs which belong to the same virtual network. When NVE
			receives BUM traffic from the attached tenant, NVE can encapsulate
			these BUM packets in unicast packets and replicate them and tunnel
			them to different remote NVEs respectively. Although this method can
			eliminate the burden of running multicast protocol in the underlay
			network, it has a significant disadvantage: large waste of bandwidth,
			especially in big-sized data center where there are many receivers.
			BIER [I-D.ietf-bier-architecture] is an architecture that provides
			optimal multicast forwarding through a "BIER domain" without
			requiring intermediate routers to maintain any multicast related per-
			flow state. BIER also does not require any explicit tree-building
			protocol for its operation. A multicast data packet enters a BIER
			domain at a "Bit-Forwarding Ingress Router" (BFIR), and leaves the
			BIER domain at one or more "Bit-Forwarding Egress Routers" (BFERs).
			The BFIR router adds a BIER header to the packet. The BIER header
			contains a bit-string in which each bit represents exactly one BFER
			to forward the packet to. The set of BFERs to which the multicast
			packet needs to be forwarded is expressed by setting the bits that
			correspond to those routers in the BIER header. Specifically, for
			BIER-TE, the BIER header may also contain a bit-string in which each
			bit indicates the link the flow passes through.
			The following sub-sections try to propose how to take full advantage
			of overlay multicast protocol to carry virtual network information,
			and create a mapping between the virtual network information and the
			bit-string to implement BUM services in data centers.
			A.1. Convention and Terminology
			The terms about NVO3 are defined in [RFC7365]. The most common
			terminology used in this appendix is listed below.
			NVE: Network Virtualization Edge, which is the entity that
			implements the overlay functionality. An NVE resides at the
			boundary between a Tenant System and the overlay network.
			VXLAN: Virtual eXtensible Local Area Network
			VNI: VXLAN Network Identifier
			Virtal Network Context Identifier: Field in an overlay encapsulation
			header that identifies the specific VN the packet belongs to.
			A.2. BIER in data centers
			This section tries to describe how to use BIER as an optimal scheme
			to forward the broadcast, unknown and multicast (BUM) packets when
			they arrive at the ingress NVE in data centers.
			The principle of using BIER to forward BUM traffic is that: firstly,
			it requires each ingress NVE to have a mapping between the Virtual
			Network Context Identifier and the bit-string in which each bit
			represents exactly one egress NVE to forward the packet to. And
			then, when receiving the BUM traffic, the BFIR/Ingree NVE maps the
			receiving BUM traffic to the mapping bit-string, encapsulates the
			BIER header, and forwards the encapsulated BUM traffic into the BIER
			domain to the other BFERs/Egress NVEs indicated by the bit-string.
			Furthermore, as for how each ingress NVE knows the other egress NVEs
			that belong to the same virtual network and creates the mapping is
			the main issue discussed below. Basically, BIER Multicast Listener
			Discovery is an overlay solution to support ingress routers to keep
			per-egress-router state to construct the BIER bit-string associated
			with IP multicast packets entering the BIER domain. The following
			section tries to extend BIER MLD to carry virtual network
			information(such as Virtual Network Context identifier), and
			advertise them between NVEs. When each NVE receive these
			information, they create the mapping between the virtual network
			information and the bit-string representing the other NVEs belonged
			to the same virtual network.
			A.3. A BIER MLD solution for Virtual Network information
			The BIER MLD solution allows having multiple MLD instances by having
			unique pairs of BMLD Nodes and BMLD Querier addresses for each
			instance. Assume for now that we have a unique instance per VNI and
			that all BMLD routers are using the same mapping between VNIs and
			BMLD address pairs. Also for each VNI there is a multicast group
			used for encapsulation of BUM traffic over BIER. This group may
			potentially be shared by some or all of the VNIs.
			Each NVE acquires the Virtual Network information, and advertises
			this Virtual Network information to other NVEs through the MLD
			messages. For a given VNI it sends BMLD reports to the BMLD nodes
			address used for that VNI, for the group used for delivering BUM
			traffic for that VNI. This allows all NVE routers to know which
			other NVE routers have interest in BUM traffic for a particular VNI.
			If one attached virtual network is migrated, the NVE will withdraw
			the Virtual Network information by sending an unsolicited BMLD
			report. Note that NVEs also respond to periodic queries to BMLD
			Nodes addresses corresponding to VNIs for which they have interest.
			When ingress NVE receives the Virtual Network information
			advertisement message, it builds a mapping between the receiving
			Virtual Network Context Identifier in this message and the bit-string
			in which each bit represents one egress NVE who sends the same
			Virtual Network information. Subsequently, once this ingress NVE
			receives some other MLD advertisements which include the same Virtual
			Network information from some other NVEs , it updates the bit-string
			in the mapping and adds the corresponding sending NVE to the updated
			bit-string. Once the ingress NVE removes one virtual network, it
			will delete the mapping corresponding to this virtual network as well
			as send withdraw message to other NVEs.
			After finishing the above interaction of MLD messages, each ingress
			NVE knows where the other egress NVEs are in the same virtual
			network. When receiving BUM traffic from the attached virtual
			network, each ingress NVE knows exactly how to encapsulate this
			traffic and where to forward them to.
			This can be used in both IPv4 network and IPv6 network. In IPv4,
			IGMP protocol does the similar extension for carrying Virtual Network
			information TLV in Version 2 membership report message.
			Note that it is possible to have multiple VNIs map to the same pair
			of BMLD addresses. Provided VNIs that map to the same BMLD address
			uses different multicast groups for encapsulation, this is not a
			problem, because each instance is tracking interest for each
			multicast group separately. If multiple VNIs map to the same pair
			and the multicast group used is not unique, some NVEs may receive BUM
			traffic for which they are not interested. An NVE would drop packets
			for an unknown VNI, but it means wasting some bandwidth and
			processing. This is similar to the non-BIER case where there is not
			a unique multicast group for encapsulation. The improvement offered
			by using BMLD is by using multiple instance, hence reducing the
			problems caused by using the same transport group for multiple VNIs.
	Authors' Addresses		Authors' Addresses
	Pierre Pfister		Pierre Pfister
	Cisco Systems		Cisco Systems
	Paris		Paris
	France		France
	Email: pierre.pfister@darou.fr		Email: pierre.pfister@darou.fr
	skipping to change at page 9, line 35 ¶		skipping to change at page 14, line 4 ¶
	Email: pierre.pfister@darou.fr		Email: pierre.pfister@darou.fr
	IJsbrand Wijnands		IJsbrand Wijnands
	Cisco Systems		Cisco Systems
	De Kleetlaan 6a		De Kleetlaan 6a
	Diegem 1831		Diegem 1831
	Belgium		Belgium
	Email: ice@cisco.com		Email: ice@cisco.com
	Stig Venaas		Stig Venaas
	Cisco Systems		Cisco Systems
	Tasman Drive		Tasman Drive
	San Jose, CA 95134		San Jose, CA 95134
	USA		USA
	Email: stig@cisco.com		Email: stig@cisco.com
			Cui(Linda) Wang
			ZTE Corporation
			No.50 Software Avenue, Yuhuatai District
			Nanjing, CA
			China
			Email: wang.cui1@zte.com.cn
			Zheng(Sandy) Zhang
			ZTE Corporation
			No.50 Software Avenue, Yuhuatai District
			Nanjing, CA
			China
			Email: zhang.zheng@zte.com.cn
	Markus Stenberg		Markus Stenberg
	Helsinki 00930		Helsinki 00930
	Finland		Finland
	Email: markus.stenberg@iki.fi		Email: markus.stenberg@iki.fi
End of changes. 16 change blocks.
	18 lines changed or deleted		232 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/